Web语义化标准解读 about kuitos.github.io HOT 16 OPEN

//button.sass

%button {
    width:80px;
    height:40px;
}

.button-primary {
    @extend %button;
    background-color: white;
}

.button-success {
    @extend %button;
    background-color: green;
}
.button-error {
    @extend %button;
    background-color: red;
}

赞博主思考，根据文章意思是只对外暴露.button-primary, .button-success, .button-error这几个class，不知道我理解对不对？

还有我想知道这种最佳实践下怎么应对哪天产品要求第一个按钮要左排第二个要右排的时候这样的需求，这个最佳实践貌似并没有解决。

from kuitos.github.io.

@rockcoder23 对于这类需求，其实文中有透露一些信息。
假设你的代码是这样的

<div class=""btn-group>
  <button class="button-primary">primary</button>
  <button class="button-errro">error</button>
</div>

第一个左移第二个右移，这样写不就好了

.btn-group {
    .button-primary {
        float:left;
     }

    .button-error {
        float:right;
    }
}

css的核心能力就是层叠啊。

from kuitos.github.io.

@kuitos 了解了~ 谢谢博主~

from kuitos.github.io.

我觉得，css全局性导致了我们得做这样的事。有了css作用域约束，我们就不用这么麻烦了。

from kuitos.github.io.

我的理解是这样，首先比较赞同利用 Sass 以达到代码复用的目的。另外上面的例子里的 button.scss 应属于页面的组件层样式，这边没有问题，但是面临页面逻辑层的需求：

哪天产品要求第一个按钮要左排第二个要右排的时候

两种方式：

• 可以利用 CSS 层叠及选择器权值来设置样式（可能会提高维护成本）
• 添加描述表现的类（违背语义）

自己更倾向于面向语义的方式，感觉如果 CSS 分层清晰，命名科学（BEM等）的话，感觉 scoped 方案，比如 CSS Modules 可能不是很有必要，感觉更多是出于组件内聚的考虑，但它生成的 class 并不满足语义。

不过个人开发还好，如果是团队开发的话，可能很难保证面向语义，感觉不是自己能控制的。

恩，随便胡扯了几句 😈 ，然后想问下：

OOCSS 减少对HTML结构的依赖

我怎么感觉它反而增加了对 HTML 结构的依赖呢？ 😢

from kuitos.github.io.

@limichange 全局性只是一方面吧，我认为主要是不具备天生的抽象能力以及我们对语义化执行的力度不够，导致面对复用这种需求时会在岔路上越走越远。

from kuitos.github.io.

@leozdgao 是的，如果做的够好，CSS Modules的存在感会小很多。
这里借机补充下，在真正实践中，我觉得应该这样操作：

组件层&抽象层，采取sass ＋ OOCSS／BEM 结合的方式写一些可复用的单元，这些单元是纯粹的内聚需要，对css而言不可见。

逻辑层 利用语义化selector(包括class钩子，属性及高级选择器等语义化手段)，组合那些使用sass编写的可复用单元。

我觉得这并不会增加维护成本，反而会在长期内减少冗余样式、不可预知的样式覆盖等维护问题。唯一的成本可能就是你在开始一个页面之前，需要去抽象一下可复用的单元，然后用sass表达出来。不过我感觉如果你采用的是正确的工作流(面向语义)，这些事情都是比较顺理成章的。

对于团队开发如何确保面向语义，这确实是一个比较难解决的问题。除了需要提供一个清晰的团队sass库说明之外，貌似只能通过一些工程化手段解决了(加强code review流程、制定规范等等)。

from kuitos.github.io.

@kuitos 嗯，认同。

from kuitos.github.io.

LZ，有问题请教下

在某xxx.less文件中：

.btn() {
  display: inline-block;
  background-image: none;
  font-size: 12px;
  text-align: center;
  vertical-align: middle;
  white-space: nowrap;
  border-radius: 4px;
  border: 1px solid transparent;
  cursor: pointer;
  touch-action: manipulation;
}

.btn-default() {
  padding: 7px 20px;
}

.btn-primary() {
  background-color: #00a0ff;
  color: #fff;

  &:hover {
    background-color: #66c6ff;
  }

  &:focus, &:active {
    background-color: #0090e6;
  }
}

.btn-default-primary {
  .btn();
  .btn-default();
  .btn-primary();
}

调用btn-default-primary样式，btn、btn-default、btn-primary样式也没暴露出来，也就是说less也有这种placeholder的功能啊。

此外，采用这种写法，多种按钮样式之前就会产生冗余吧，这种情况和LZ在文中提到的该如何权衡呢？

from kuitos.github.io.

@ruohuan less的这个是mixin,mixin是include样式而不是placeholder那种合并的方式。你对比一下就知道了。对于button这种不需要传入变量的抽象单元，我觉得minix的方式不合适。而可惜的是less没有placeholder这种设计。

如果是合并而不是简单的include，自然也不会产生冗余的问题。

from kuitos.github.io.

@kuitos 了解了，谢LZ

from kuitos.github.io.

《贺老博文和知乎回答之汇总详解》，哈哈。

from kuitos.github.io.

@Justineo nonono，不仅如此，准确来说是 《贺老&10博文和知乎回答之汇总详解》 😂

from kuitos.github.io.

感谢@kuitos对Web语义化的解读

from kuitos.github.io.

这篇文章真是好，昨天看过之后又补充了一些相关的知识，再回来看一遍，估计还要再看几遍才能理解&应用。谢谢！

from kuitos.github.io.

组件层&抽象层，采取sass ＋ OOCSS／BEM 结合的方式写一些可复用的单元，这些单元是纯粹的内聚需要，对css而言不可见。

@kuitos

文章真的好 但还有一些疑问 上述提到的 placeholder、mixin 之类的该如何命名呢 如果要保证绝对的通用那么名称势必得特别的抽象 题例您定义了一个名为 button 的类 那么名称决定了这个类的实例只能是按钮啊 限制了复用啊~

from kuitos.github.io.