我正在尝试围绕 CSS 中的 BEM 命名进行思考,并且想知道我是否正确理解它。
根据官方文档,一个元素是:
块的一部分,没有独立的含义并且在语义上与其块相关联。
鉴于下面的代码片段,没有任何子项.main-nav具有任何独立的含义,所以我相信它们都可以作为一个元素。
但是,当我最终得到像.main-nav__sub-menu-item-link. 感觉就像我仍然嵌套了好几层,就在我的元素名称空间中。
也许这完全没问题,下面的例子是正确的实现,我只是欣赏第二个意见。
<nav class="main-nav">
<div class="main-nav__logo">
<a class="main-nav__logo-link">Company Name</a>
</div>
<ul class="main-nav__menu">
<li class="main-nav__menu-item">
<a class="main-nav__menu-item-link">Products</a>
<ul class="main-nav__sub-menu">
<li class="main-nav__sub-menu-item">
<a class="main-nav__sub-menu-item-link">Foo</a>
</li>
<li class="main-nav__sub-menu-item">
<a class="main-nav__sub-menu-item-link">Bar</a>
</li>
<li class="main-nav__sub-menu-item">
<a class="main-nav__sub-menu-item-link">Baz</a>
</li>
</ul>
</li>
<li class="main-nav__menu-item">
<a class="main-nav__menu-item-link">Services</a>
</li>
<li class="main-nav__menu-item">
<a class="main-nav__menu-item-link">About Us</a>
</li>
</ul>
</nav>Run Code Online (Sandbox Code Playgroud)
例如,我有一个带菜单元素的菜单块:
.menu
.menu__element
.menu__element--current
Run Code Online (Sandbox Code Playgroud)
但是让我们说.menu块被包含在另一个块中,.header
在这种情况下如何处理命名?
.header
.header__menu
.header__element
Run Code Online (Sandbox Code Playgroud)
要么
.header
.header__menu
.header__menu__element
Run Code Online (Sandbox Code Playgroud)
要么
.header
.menu
.menu__element
Run Code Online (Sandbox Code Playgroud) 有了BEM的美国医学,说我有两个这样的课:
.staff__teacher
和 .staff__teacher--professor
在教授的标记中,想法是同时拥有两个类还是仅修改类?
<div class='staff__teacher staff__teacher--professor'></div>
要么
<div class='staff__teacher--professor'></div>
从我的观点来看,后者更有意义,因为它更简化,更容易阅读.
在Sass中,通过简单地扩展.staff__teacher类来创建类
.staff__teacher--professor{
@extends .staff__teacher;
//...extra professor styles here..
}
Run Code Online (Sandbox Code Playgroud)
但是,在我在BEM上看到的大多数教程中,两个类都被添加到标记中.有人可以帮助我理解一种方式是否优于另一种方式?使用我的方法可能会导致任何问题吗?
我正在尝试拾取并理解CSS命名约定背后的原因,例如BEM或SUITCss.在SCSS存在的情况下,我很难理解后代类名的价值.
例如:
<ul class="menu">
<li class="menu__item"></li>
<li class="menu__item"></li>
<li class="menu__item">
<a href="#" class="menu__item_link">link</a>
</li>
</ul>
.menu {
.menu__item {
//styles
.menu__item__link { //styles }
}
//or alternatively this syntax..
&__item { //styles }
}
Run Code Online (Sandbox Code Playgroud)
由于能够在SCSS中嵌套规则,我没有看到令人信服的理由让我在我的代码中包含祖先类名.上面我已经定义了样式,这些样式只能用于"菜单"中的"项目",使用后代类名.但是,嵌套结构已经传达了这个!menu__item的规则只适用于菜单下的项目,为什么我需要在类名中包含它?
为什么不:
<ul class="menu">
<li class="item"></li>
</ul>
.menu {
.item {//styles}
}
Run Code Online (Sandbox Code Playgroud)
我知道后代命名约定更明确,也许更适合未来.然而,我认为它只是在html中更明确.如果我想咨询如何构建这个"菜单"模块,我可以查阅CSS并清楚地看到菜单如何嵌套在里面的项目.
我想一个可能的优点是我可以编写我的css un-nested,就像这样:
.menu { //styles }
.menu__item { //styles }
.menu__item__link { //styles }
Run Code Online (Sandbox Code Playgroud)
然后在任何地方使用"menu__item",它仍然在类名中明确表示这是菜单下项目的样式.但那么为什么要将它定义为菜单的后代呢?(我认为,另一个优点是,如果没有嵌套,则CSS标识符字符串更短)
在我看来,如果一个类名被用作另一个的后代,那么在SCSS中嵌套可以实现这一点,并清楚地呈现该逻辑.为什么这个BEM语法是必要的呢?
我想听听有人解释这种类型的惯例的原因.我想坚持所谓的最佳实践,但我很难盲目地这样做,而不是完全理解一个约定.
阅读BEM CSS并使用编写一些小网站 - 我对它非常熟悉.但是,我仍然不确定如何处理非常相似的块,但没有关系.
假设我有很多无序列表块,它们的顶行都有相同的样式.其他列表项可以不同的方式布局,并且彼此完全无关.
我发现自己将块命名为它(例如'latest-news','coming-events'),然后将所有这些块堆叠在CSS中变得很麻烦 - 更不用说难以管理了.
欣赏这些东西不是一个适合所有解决方案; 但想象很多人会遇到同样的问题.调用这些块,"标准列表"然后将列表项作为块是不是更有效?
似乎违背了BEM试图实现的整个原则.我应该可以把"最新新闻"放在我想要的任何地方.这样我就必须得到保存最新新闻内容的正确"标准列表"?
希望不要太混乱!任何建议都会很棒!
我正在使用Sass 3.4.1和BEM所以我的scss是:
.photo-of-the-day{
&--title{
font-size: 16px;
}
}
Run Code Online (Sandbox Code Playgroud)
而且我希望每次都悬停在.photo-of-the-day带有标题的事情上,这通常在css中很常见:
.photo-of-the-day:hover .photo-of-the-day--title{
font-size:12px
}
Run Code Online (Sandbox Code Playgroud)
事情是使用BEM这是我发现的唯一方式,看起来有点难看
.photo-of-the-day{
&--title{
font-size: 16px;
}
&:hover{
background: red;
/* this is ugly */
.photo-of-the-day--title{
text-decoration: underline;
}
}
}
Run Code Online (Sandbox Code Playgroud)
所以我想知道我是否可以继承.photo-of-the-day选择器并在悬停内部使用它以避免再次复制完整选择器.
理想情况下会是这样的:
.photo-of-the-day{
&--title{
font-size: 16px;
}
&:hover{
background: red;
&&--title{
text-decoration: underline;
}
}
}
Run Code Online (Sandbox Code Playgroud)
或者接近回归到BEM的父选择器的东西.可能吗?
鉴于一些造型和一个附加的类(一个元素mywidget_button -禁用),它作为BEM修饰符,确实具有意义,因为实际应用中,使用重要!条款?
.mywidget__default ~ .mywidget__button {
border: 1px solid #000;
}
.mywidget__button--disabled {
border: 1px solid transparent !important;
}
Run Code Online (Sandbox Code Playgroud)
第一个类更具体,并且在第二个类中胜出,但作为禁用类的一个修饰符(理论上)应该比"常见"样式具有更高的优先级,依赖于!important子句是否正确?
或者它是否使代码容易出现意大利面?
我不确定哪个是官方网站,我找到了getbem.com和en.bem.info。
一种建议使用--修饰符(Naming):
CSS 类由块或元素的名称加上两个破折号组成。
另一个_用于修饰符(修饰符名称):
修饰符名称由单个下划线 (_) 分隔。
我知道我可以使用任何一个,而且保持一致确实很重要,但我喜欢尽可能尝试使用官方规范。
--还是_用于修饰符..?所以我开始将我的 sass 写到 BEM 公约中。我已经使用sass-lint 配置生成器来创建我的配置,并且只将class-name-format's编辑为- convention:,strictbem但是我仍然遇到一些问题。
也许我误解了 BEM?
错误:
[sass-lint] 类 '
.bus__tyre--front' 应该以 BEM(块元素修饰符)格式(class-name-format)编写<element class="bus__tyre--front">
萨斯:
.bus {
position: relative;
&__tyre {
position: absolute;
&--front {
bottom: -22px;
right: 3%;
width: 17%;
}
}
}
Run Code Online (Sandbox Code Playgroud)
sass-lint.yml:
# sass-lint config generated by make-sass-lint-config v0.1.2
#
# The following scss-lint Linters are not yet supported by sass-lint:
# DisableLinterReason, ElsePlacement, PropertyCount, SelectorDepth
# SpaceAroundOperator, TrailingWhitespace, UnnecessaryParentReference, Compass::*
#
# The …Run Code Online (Sandbox Code Playgroud) 我试图在 BEM 中表达一个简单的 CSS3 选择器:
CSS
.block__elem {
/* ELEM RULES */
}
.block__subelem {
/* SUBELEM RULES */
}
.block__elem:not(:last-child) .block__subelem {
/* HOW CAN I EXPRESS THIS? */
}
Run Code Online (Sandbox Code Playgroud)
HTML
<div class="block__elem">
<div class="block__subelem">CONTENT</div>
<div class="block__subelem2">OTHER CONTENT</div>
</div>
<div class="block__elem">
<div class="block__subelem">CONTENT</div>
<div class="block__subelem2">OTHER CONTENT</div>
</div>
<div class="block__elem">
<div class="block__subelem">THIS SHOULD HAVE A SLIGHTLY DIFFERENT STYLE</div>
<div class="block__subelem2">OTHER CONTENT</div>
</div>
Run Code Online (Sandbox Code Playgroud)
如何用 BEM 术语表达最后一个选择器?
我能想到的唯一方法是添加一个修饰符
.block__subelem--not-last-child {
}
Run Code Online (Sandbox Code Playgroud)
然后从后面将逻辑添加到 HTML 中,但对我来说这是错误的,它增加了服务器端的复杂性并且容易出错。