SMACSS，BEM和OOCSS不是可移植的？ [英] Are SMACSS, BEM and OOCSS not as portable?
问题描述
我有一个OOCSS的问题。
我的例子：
我有一个小部件的感言。在主要内容主体（具有白色背景）中，推荐文件具有黑色字体。
在OOCSS之前，我会做这样的事情：
＃main-content .testominial {
color：＃000000;
}
#footer .testominial {
color：#FFFFFF;
}
使用这种旧方法，我可以从内容区域到页脚和颜色只是工作 - 我不需要改变我的CSS或DOM类的小部件。
使用新的OOCSS / BEM，我不应该将.testimonial类耦合到ID（或位置），而是应该像这样子类化：
.testominial {
color：＃000000;
}
.testominial - footer {
color：#FFFFFF;
}
问题是我无法再从内容中拖拽我的推荐区域到页脚，而不进入DOM和更改在验证小部件上的类 - 这是LESS便携式，因为它需要开发人员手动干预;而在编辑者可以只是拖动它和样式是自动的。
我错过了什么？
您需要考虑删除考虑这个例子：
.primary-box {}
.primary-box - reduced {}
.primary-box--在此示例中，类完全独立于其页面上下文。在本示例中，类是完全独立于页面上下文的。{/ 2}结果是类是完全可重复使用的。
例如，您可以拥有：
< header>
< div class ='primary-box primary-box - reduced'>< / div>
< / header>
< div class ='content-box'>
< p class ='primary-box primary-box - standout'>< / p>
< / div>
< footer>
< div class ='primary-box primary-box - reduced'>< / div>
< / footer>
现在，当设计师回来调整突出框的填充时，可以直接转到这些样式并调整它们，相信只有在HTML中具有这些类的区域才会受到影响。
此外，当您决定移动 .primary-box - reduced 从< header> 进入其上方的菜单栏或页脚，
当你需要另一个元素，也许一个主框 - 突出，或只是一个默认的主框，你只需创建它并添加类，它们的样式将完全遵循。
你永远不会继承意想不到的风格。
这是一个很现实的例子，几乎所有的建设都是这样的，我说几乎所有因为我还在学习，但我可以保证我在一个快速移动的项目与最流行的设计是最少的麻烦，那些具有非特定的上下文。 p>
重要的是缺乏上下文。在第一个例子中， .testimonial - footer 非常依赖于上下文，你真的需要在页脚中的推荐上使用它。
如果是魔法 CSS Wizardry涵盖了这个确切的主题
编辑：我添加了这个例子来帮助我对我的回答发表评论。这不是BEM或OOCSS，尽管它更接近 SMACSS方法。这是我如何处理css的问题，是一种混合BEM / SMACSS方法：
按顺序加载：
- 模块文件，例如
.primary-box
- 页面部分文件，例如
.header 或 .call-to-action
- 页面文件，例如
.about-us 或 .contact
每个文件变得越来越具体，同时构建更复杂和模块。基于上面的例子，希望可以帮助OP，你可以看到如下样式：
.header {
.primary -box {
color：＃000;
}
}
这将覆盖模块样式特定的嵌套类符号。请注意，我仍然会避免使用类名称，例如 .header - .banner-standout
接下来，您甚至可以看到：
.about-us {
.header {
.primary-box {
color：＃f00;
}
}
}
在实际项目中为上下文，同时保留BEM的上下文自由的力量，虽然我也敦促尽可能推动这个链条进入模块。如果我认识到一个新的通用页面部分或模块，并适当地重新组织命名和文件，生活是更容易。在一个项目中，代码已被重构，请小心我没有页面文件。
SO I have a problem with OOCSS. It is supposed to be more portable but compared to how I usually do things, I'm finding it less so.
My example:
I have a widget testimonial. In the main content body (which has a white background) the testimonial has a black font. But in the footer (which has a blue background) the testimonial needs a white font.
Before OOCSS, I would do something like this:
#main-content .testominial {
color: #000000;
}
#footer .testominial {
color: #FFFFFF;
}
With this "old" approach, I could drag my widget from the content area to the footer and the colours would simply work - I wouldn't need to change my CSS or DOM classes of the widget.
With the new OOCSS/BEM, I am NOT supposed to couple the .testimonial class to the ID (or to the location), but rather I should subclass it like so:
.testominial {
color: #000000;
}
.testominial--footer {
color: #FFFFFF;
}
The problem with this is that I can no longer drag my testimonial from the content area to the footer without going into the DOM and changing the classes on the testimonial widget - It is LESS portable as it requires manual intervention by a developer; whereas before an editor could just drag it and the styling was automatic.
Am I missing something? There seems to be no solid real-world examples out there?
解决方案 You need to consider dropping the testimonial naming as well as the footer.
Consider this example:
.primary-box { }
.primary-box--reduced { }
.primary-box--standout { }
In the example the classes are completely independent of their page context. The result is that the classes are completely re-usable. Any box on the page can take the classes above and expect to be styled exactly as defined.
For example, you could have:
<header>
<div class='primary-box primary-box--reduced'></div>
</header>
<div class='content-box'>
<p class='primary-box primary-box--standout'></p>
</div>
<footer>
<div class='primary-box primary-box--reduced'></div>
</footer>
Now when the designer comes back and tweaks the padding of the standout boxes you can go directly to those styles and tweak them, confident that the only areas that will be effected will be the areas that have those classes in the HTML.
Also, when you decide to move .primary-box--reduced from the <header> into the menu bar that sits above it, or into the footer, you can be confident that the styles will come along, completely.
When you need another element somewhere, perhaps a primary-box--standout, or just a default primary-box in the header, you just create it and add the classes, they styles will follow completely.
You'll never inherit unexpected styles either.
This is very much a real world example, a site I built recently was almost all built like this, I say almost all because I'm still learning, but I can guarantee the bits I had the least trouble with on a fast-moving project with very fluid designs were the ones with non-specific context.
What's important is the lack of context. In the first example, .testimonial--footer is very context dependent, you really need to use it on testimonials in the footer only.
And as if by magic CSS Wizardry cover this exact topic
EDIT: I added this example to help with a comment made on my answer. This isn't BEM, or OOCSS, though it is a bit closer to the SMACSS approach. It's how I tackle problems with css and is a hybrid BEM / SMACSS approach:
Loaded in order:
- module files, such as
.primary-box
- page section files, such as
.header or .call-to-action
- page files, such as
.about-us or .contact
Each file gets more and more specific, while simultaneously building more complex and modules. Building on the examples above and hopefully helping the OP, you could see styles like:
.header {
.primary-box {
color: #000;
}
}
which would over-ride the module styles using a more specific nested class notation. Please note, I would still avoid using a class name like .header - .banner-standout would be better as it's re-usable anywhere without confusion
Next, you could even see:
.about-us {
.header {
.primary-box {
color: #f00;
}
}
}
I find this works very well in real projects for context while retaining the context free power of BEM, though I would also urge as much as possible to push up this chain into the modules. Life is easier if I recognise a new generic page section or module and re-organise the naming and files appropriately. In a project where the code has been refactored with care I have nothing in page files.
这篇关于SMACSS，BEM和OOCSS不是可移植的？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
