合理CSS的核心原则，摘自CSS重构:从仅追加到模块化CSS

Write in SASS. You'd be insane to forego the advantages of variables, mixins, and so on. Never use an HTML ID for styling; always use classes. HTML IDs, when used correctly, appear only once in the whole page, which is the complete opposite of re-usability — one of the most basic goods in sensible engineering. Moreover, it's really hard to override selectors containing IDs and often the only way to overpower one HTML ID is to create another ID, causing IDs to propagate in the codebase like the pests they are. Better to leave the HTML IDs for unchanging Javascript or integration test hooks. Name your CSS classes by their visual function rather than by their application-specific function. For example, say ".highlight-box" instead of ".bundle-product-discount-box". Coding in this way means that you can re-use your existing style-sheets when you role out side-businesses. For example, we started out selling law notes but recently moved into law tutors. Our old CSS classes had names like ".download_document_box", a class name that makes sense when talking about digital documents but would only confuse when applied to the new domain of private tutors. A better name that fits both existing services — and any future ones — would be ".pretty_callout_box". Avoid naming CSS classes after specific grid information. There was (and still is) a dreadful anti-pattern in CSS communities whereby designers and creators of CSS frameworks (cough Twitter Bootstrap) believe that "span-2" or "cols-8" are reasonable names for CSS classes. The point of CSS is to give you the possibility to modify your design without affecting the markup (much). Hardcoding grids sizes into the HTML thwarts this goal, so it is advised against in any project expected to last longer than a weekend. More on how we avoided grid classes later. Split your CSS across files. Ideally you would split everything into "components"/"widgets" and then compose pages from these atoms of design. Realistically though, you'll notice that some of your website pages have idiosyncrasies (e.g. a special layout, or a weird photo gallery that appears in just one article). In these cases you might create a file related to that specific page, only refactoring into a full-blown widget when it becomes clear that the element will be re-used elsewhere. This is a tradeoff, one that is motivated by practical budgetary concerns. Minimise nesting. Introduce new classes instead of nesting selectors. The fact that SASS removes the pain of repeating selectors when nesting doesn't mean that you have to nest five levels deep. Never over-qualify a selector (e.g. don't use "ul.nav" where ".nav" could do the same job.) And don't specify HTML elements alongside the custom class name (e.g."h2.highlight"). Instead just use the class name alone and drop the base selector (e.g. the previous example should be ".highlight"). Over-qualifying selectors doesn't add any value. Create styles for HTML elements (e.g. "h1") only when styling base components which should be consistent in the whole application. Avoid broad selectors like "header ul" because it's likely that you have to override them in some places anyway. As we keep saying, most of the time you want to use a specific, well-named class whenever you want a particular style. Embrace the basics of Block-Element-Modifier. You can read about it for example on here. We used it quite lightly, but still it helped us a lot in organising CSS styles.

看一看 1. 萨斯 2. 指南针

我发现最难的事情是将网站所需的设计转化为一系列规则。如果站点的设计清晰且基于规则，那么你的类名和CSS结构就可以由此而来。但是，如果人们随着时间的推移，随机地在网站上添加一些没有多大意义的内容，那么在CSS中就没有太多办法了。

我倾向于这样组织我的CSS文件:

CSS reset, based on Eric Meyer’s. (Because otherwise I find that, for most elements, I’ve got at least one or two rules that are just resetting default browser styles — most of my lists don’t look like the default HTML style for lists, for example.) Grid system CSS, if the site calls for it. (I base mine on 960.gs) Styles for components that appear on every page (headers, footers, etc) Styles for components that are used in various places across the site Styles that are only relevant on individual pages

如你所见，这主要取决于网站的设计。如果设计清晰有条理，你的CSS也可以做到。如果不是，你就完蛋了。

这是一个非常好的问题。在我所看到的任何地方，CSS文件都倾向于在一段时间后失去控制——尤其是，但不仅仅是在团队中工作时。

以下是我自己努力遵守的规则(并不是说我总能做到)。

Refactor early, refactor often. Frequently clean up CSS files, fuse together multiple definitions of the same class. Remove obsolete definitions immediately. When adding CSS during fixing bugs, leave a comment as to what the change does ("This is to make sure the box is left aligned in IE < 7") Avoid redundancies, e.g. defining the same thing in .classname and .classname:hover. Use comments /** Head **/ to build a clear structure. Use a prettifier tool that helps maintain a constant style. I use Polystyle, with which I'm quite happy (costs $15 but is money well spent). There are free ones around as well (e.g. Code Beautifier based on CSS Tidy, an open-source tool). Build sensible classes. See below for a few notes on this. Use semantics, avoid DIV soup - use <ul>s for menus, for example. Define everything on as low a level as possible (e.g. a default font family, colour and size in the body) and use inherit where possible If you have very complex CSS, maybe a CSS pre-compiler helps. I'm planning to look into xCSS for the very same reason soon. There are several others around. If working in a team, highlight the necessity of quality and standards for CSS files as well. Everybody's big on coding standards in their programming language(s), but there is little awareness that this is necessary for CSS too. If working in a team, do consider using Version Control. It makes things that much easier to track, and editing conflicts that much easier to solve. It's really worth it, even if you're "just" into HTML and CSS. Do not work with !important. Not only because IE =< 7 can't deal with it. In a complex structure, the use of !important is often tempting to change a behaviour whose source can't be found, but it's poison for long-term maintenance.

构建合理的类

这就是我喜欢构建合理类的方式。

我首先应用全局设置:

body { font-family: .... font-size ... color ... }
a { text-decoration: none; }

然后，我确定页面布局的主要部分。顶部区域、菜单、内容和页脚。如果我写了好的标记，这些区域将与HTML结构相同。

然后，我开始构建CSS类，在合理的情况下指定尽可能多的祖先，并将相关类尽可能紧密地分组。

div.content ul.table_of_contents 
div.content ul.table_of_contents li 
div.content ul.table_of_contents li h1
div.content ul.table_of_contents li h2
div.content ul.table_of_contents li span.pagenumber

你可以把整个CSS结构想象成一棵树，它的定义越远越具体。你想要尽可能地减少课程的数量，并且尽可能少地重复学习。

例如，假设您有三个级别的导航菜单。 这三个菜单看起来不同，但它们也有一些共同的特征。例如，它们都是<ul>，它们都有相同的字体大小，并且项目都是彼此相邻的(与ul的默认呈现相反)。此外，所有菜单都没有项目符号(list-style-type)。

首先，在一个名为menu的类中定义公共特征:

div.navi ul.menu { display: ...; list-style-type: none; list-style-image: none; }
div.navi ul.menu li { float: left }

然后，定义这三个菜单的具体特征。第1级是40像素高;2级和3级，20像素。

注意:您也可以为此使用多个类，但Internet Explorer 6在使用多个类时存在问题，因此本例使用id。

div.navi ul.menu#level1 { height: 40px; }
div.navi ul.menu#level2 { height: 20px; }
div.navi ul.menu#level3 { height: 16px; }

菜单的标记看起来像这样:

<ul id="level1" class="menu"><li> ...... </li></ul>
<ul id="level2" class="menu"><li> ...... </li></ul>
<ul id="level3" class="menu"><li> ...... </li></ul>

如果页面上有语义相似的元素(比如这三个菜单)，首先试着找出共性，然后把它们放到一个类中;然后，计算出特定的属性并将它们应用到类中，或者，如果您必须支持Internet Explorer 6，则应用ID。

其他HTML技巧

如果你将这些语义添加到HTML输出中，设计师以后可以使用纯CSS定制网站和/或应用程序的外观，这是一个很大的优势和节省时间。

If possible, give every page's body a unique class: <body class='contactpage'> this makes it very easy to add page-specific tweaks to the style sheet: body.contactpage div.container ul.mainmenu li { color: green } When building menus automatically, add as much CSS context as possible to allow extensive styling later. For example: <ul class="mainmenu"> <li class="item_first item_active item_1"> First item </li> <li class="item_2"> Second item </li> <li class="item_3"> Third item </li> <li class="item_last item_4"> Fourth item </li> </ul> This way, every menu item can be accessed for styling according to its semantic context: Whether it's the first or last item in the list; Whether it's the currently active item; and by number.

请注意，如上例中所述的多个类的分配在IE6中不能正常工作。有一个变通方案可以使IE6能够处理多个类。如果没有解决方法，则必须设置对您来说最重要的类(项目编号、活动或第一个/最后一个)，或者使用id。

这里有一些很棒的材料，有些人已经花了很多时间来回答这个问题，但是当涉及到单独或单独的样式表时，我会使用单独的文件进行开发，然后在部署时将所有在站点上使用的通用css合并到一个文件中。

这样你可以两全其美，提高性能(从浏览器请求的HTTP请求更少)，并在开发时分离代码关注点。

以下是4个例子:

CSS约定/代码布局模型 在编写我的第一个样式表时，我应该遵循哪些CSS标准? 整理CSS的最佳方法是什么? 最佳实践- CSS样式表格式

在所有4个问题上，我的回答都包含了下载并阅读Natalie Downe的PDF CSS系统的建议。(PDF包含了大量幻灯片上没有的注释，所以请阅读PDF!)注意她对组织的建议。

四年后，我想说:

Use a CSS pre-processor and manage your files as partials (I personally prefer Sass with Compass, but Less is quite good as well and there are others) Read up on concepts like OOCSS, SMACSS, and BEM or getbem. Take a look at how popular CSS frameworks like Bootstrap and Zurb Foundation are structured. And don't discount less popular frameworks - Inuit is an interesting one but there are plenty others. Combine/minify your files with a build step on a continuous integration server and/or a task runner like Grunt or Gulp.