我可以建议少CSS动态框架吗

它类似于前面提到的SASS。

它帮助维护每个父类的CSS。

E.g.

 #parent{     
  width: 100%;

    #child1
    {    
     background: #E1E8F2;    
     padding: 5px;    
    }

    #child2
   {
     background: #F1F8E2;
     padding: 15px
   }
 }

它的作用: 将width:100%应用于#child1和#child2。

此外，#child1特定的CSS属于#parent。

这将导致

#parent #child1
{
 width: 100%;
 background: #E1E8F2;
 padding: 5px;
}

#parent #child2
{
 width: 100%;
 background: #F1F8E2;
 padding: 15px;
}

你应该看看边界元法。

理论

BEM试图提供一组用于组织和命名css选择器的指令，以使选择器更具可重用性和模块化，并避免选择器之间的冲突，这种冲突通常会导致意大利面条式的代码和特定的问题。

如果正确使用，它实际上有一些非常积极的影响。

当样式被添加到元素中时，它们的作用是您所期望的 样式不会泄露，并且只影响它们所添加的内容 样式与文档结构完全解耦 不同的风格不需要被强迫凌驾于彼此之上

BEM works well with SASS to bring an almost object oriented style to CSS. You can build modular files, that handle the display of a single UI element and contain variables, such as colours and 'methods' such as how internal elements are handled. While a hardcore OO programmer might balk at this idea, in fact, the applied concepts bring in a lot of the nicer parts of OO structures, such as modularity, loose coupling and tight cohesion and context free re-usability. You can even build in a way that looks like an encapsulated object by using Sass and the & operator.

更多来自Smashing杂志的深入文章可以在这里找到;还有一个来自CCS Wizardry的Harry Roberts(任何参与css的人都应该读一下他的书)。

在实践中

我已经用过它几次了，还用过SMACSS和OOCSS，这意味着我也可以对它们进行比较。我也在一些大混乱中工作过，通常是我自己没有经验的创作。

当我在现实世界中使用BEM时，我用一些额外的原则来增强这种技术。我利用实用工具类-一个很好的例子是包装类:

.page-section {
    width: 100%;
}
@media screen and (min-width: 1200px) {
    margin: 0 auto;
    width: 1200px;
}

我也有些依赖于级联和特异性。在这里，BEM模块将是.primary-box，而.header将是特定重写的上下文

.header {
  .primary-box {
    color: #000;
  }
}

(我尽我最大的努力使所有的东西都是通用的和上下文无关的，这意味着一个好的项目几乎所有的东西都在可重用的模块中)

我想说的最后一点是，无论你的项目看起来多么小，多么简单，你都应该从一开始就这么做，原因有二:

项目越来越复杂，所以打下良好的基础是很重要的，包括CSS 即使是一个看起来很简单的项目，因为它是建立在WordPress上的，JavaScript很少，但在CSS中仍然非常复杂——好吧，你不需要做任何服务器端编码，所以这部分很简单，但是宣传册前端有20个模块和每个模块的3个变体:你有一些非常复杂的CSS !

Web组件

在2015年，我们开始关注Web组件。我对这些还不太了解，但它们希望将所有前端功能放在自包含的模块中，有效地尝试将各种原则从BEM应用到前端作为一个整体，并将分散但完全耦合的元素(如DOM片段、Js (MVC)和CSS)组合在一起，这些元素都构建相同的UI小部件。

通过这样做，他们b将解决css中存在的一些原始问题，我们试图用BEM等东西来解决这些问题，同时使其他一些前端架构更加合理。

这里有一些进一步的阅读材料，还有一个框架聚合物，非常值得一看

最后

我也认为这是一个优秀的、现代的css最佳实践指南——专门为防止大型css项目变得混乱而设计。我尽量遵循其中的大部分。

就像我之前说的:进入OOCSS。Sass/Less/Compass使用起来很诱人，但在正确使用CSS之前，Sass/Less/Compass只会让事情变得更糟。

首先，阅读高效css。尝试谷歌页面速度和阅读Souders关于高效css的文章。

然后进入OOCSS。

学会使用级联。(毕竟，我们称之为级联样式表)。 学习如何获得正确的粒度(自底向上而不是自顶向下) 学习如何分离结构和皮肤(什么是唯一的，这些对象的变化是什么?) 学习如何分离容器和内容。 学会爱上网格。

它将彻底改变css的每一个细节。我完全焕然一新，爱上了它。

更新:SMACSS类似于OOCSS，但一般来说更容易适应。

我的回答是高水平的，针对你刚才提到的高水平的关切。也许你可以通过一些低级的组织技巧和调整来使它更漂亮，但这些都不能解决方法上的缺陷。有几个因素会影响CSS的爆炸。显然是网站的整体复杂性，但还有像命名语义、CSS性能、CSS文件组织和可测试性/可接受性等问题。

在命名语义方面，您似乎走在了正确的道路上，但还可以更进一步。重复出现在站点上而没有进行结构修改的HTML部分(称为“模块”)可以被视为选择器根，从那里您可以相对于根确定内部布局的范围。这是面向对象的CSS的基本原则，您可以在Yahoo工程师的演讲中阅读/观看更多关于它的内容。

需要注意的是，这种干净的方法可能与性能问题相反，它倾向于基于id或标记名的短选择器。找到平衡取决于你，但除非你有一个庞大的网站，这应该只是一个指南在你的脑后提醒你保持你的选择器简短。这里有更多关于性能的信息。

最后，您将为整个网站使用一个CSS文件，还是多个文件(单个基本文件用于每个页面或-section文件)?单个文件对于性能来说更好，但是对于多个团队成员来说可能更难理解/维护，并且可能更难测试。对于测试，我建议您使用一个CSS测试页面，其中包含所有受支持的CSS模块，以测试冲突和意外级联。

或者，您也可以采用多文件方法，将CSS规则作用于一个页面或一个部分。这需要浏览器下载多个文件，这是一个性能问题。您可以使用服务器端编程动态地指定和聚合(并缩小)CSS文件到单个文件中。但是，由于这些文件是分开的，对它们的测试也是分开的，因此可能会在页面/部分之间引入不一致的外观。因此测试变得更加困难。

由你来分析客户的具体需求，并相应地平衡这些问题。

合理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.

这是一个非常好的问题。在我所看到的任何地方，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。