从观麦前端框架的角度看css

兼容

pc web：比如 MA Station。基于chrome，可以手机访问（需要业务做适配）。 android 上兼容 微信浏览器 和 QQ浏览器，safari 支持 iOS > 8（safari 的版本随系统版本）。比较任性。

mobile web：比如 下单系统。主要在微信浏览器内访问。

safari 的兼容测试可以用 mac 自带的模拟器 simulator 来测试，非常方便。

bootstrap

基于老牌的 bootstrap，相对简单易用。v4 现在还在 beta 中，如果正式了还是可以考虑迁移的。或者 beta 阶段迁移。

less

因为 bootstrap3 是 less ，移动端基于所以也就用了 less， 实际上 sass 更强大。bootstrap4 也采用了 sass。等迁移到 bootstrap4 后我们也会采用 sass 的，就是这么任性。

less 函数有个特性有点奇怪，我用过，不过不具备可维护性，不建议大家用。

// 正常情况

.fun1(){
    background: red;
}

.aaa{
    .fun1();
}

// 一个类名也可以当函数用，不建议用
.class1{
    background: red;
}

.aaa{
    .class1();
}

flex

web 开发都是基于 flex 的，这给我们的布局很大的方便，非常的灵活，可以很简单的。

上面系统的整体兼容性也基本是考虑 flex 的兼容上。

要特别注意的地方是 flex-shrink 即项目的缩小比例，默认为1，即如果空间不足，该项目缩小。 但是不推荐直接操作 flex-shrink，而是用 flex: none 或者 flex: auto。

移动端高清屏1px

框架用的方法是 scale(0.5) 方法。不过多介绍，(网上文章很多)[https://juejin.im/entry/584e4...

命名

没有前缀的 btn 是 bootstrap，前缀 gm- 是 react-gm 库的。 b- 是 业务内的。(连接符-)

模块内部的命名保留模块，即

// good 长是长了点，但是可维护性可读性很强
.b-home{
    .b-home-top{
        background: red;
        .b-home-top-btn{
            background: white;
        }
    }
}
// bad 因为可能其他库有定义了 top 这个样式。 这样就会有被覆盖的可能性。
.b-home{
    .top{
        background: red;
    }
}

特殊的类名除外，比如 disabled checked error in out on off 等除外。

.b-home{
    .b-home-top{
        .disabled{
            background: gray;
        }
    }
}

less 变量命名同上，只是换成了骆驼峰，去掉了连接符

命名上有个出名的 BEM ，不了解，哈哈。

组合思想

目标是开发者想实现什么样式，通过 react-gm bootstrap 提供的类名来组合即可，这要求他们提供的类名足够丰富。当然这个想法已经满足了。

至于可能会出现某些场景不满足的（肯定会有），做法是

1 是否场景不合理？也可能是故意约束，克制，不提供此功能。
2 提出来讨论，共同抽象，沉淀到 react-gm 上。
3 实在特殊的就特殊处理，直接写在style上。

那组合思想是，其实 bootstrap 也是组合思想

<div className="gm-border gm-padding-5 gm-bg"></div>

<btn className="btn btn-primary btn-lg disabled"></div>

组合思想带来的好处是

1 可读性和可维护性增强，通过 className 能想象出 UI。
2 速度快，直接写 jsx 即可。 不用来回切换 js/html css 文件。

分离css

以前 css 是通过 webpack 打包在 js 内的，这样带来的坏处是

• js 要处理这些 css，自然需要花费时间。同时还阻塞其他 js 代码的执行时间。
• 按照组合思想开发，理论上 css 会很少改动，js 确实常改动。这样 css 没法独立缓存。
• 如果有 dom 的话，会是先 dom 出来，之后加载 js 处理 css 部分。这时会看到页面没样式，突然又有样式的闪烁，不太好。理论上 css 最好释放 head 提前 load。

所以就分离了呗。

降级处理

通过 autoprefixer 来做降级，比如

// 原来
display: flex;

// 处理后
display: -webkit-box;
display: -webkit-flex;
display: flex;

细心的同学可以发现，只有 -webkit-，没有 -ms- -moz- -o-。从兼容性上来考虑，只处理 -webkit- 已足够。

css module

有短时间引入了 css module，不过现在用的很少了。 当成的目的是 css module 模块化，但是带来了一些问题

• css(less) 模块化后随 js 的引入而引入，css 即异步加载的
• 以此同时 less 并没有在主框架上，因此没法使用 变量 函数 等。

于是慢慢废弃。

随着 react-gm 提供的类名组件完善，后面真正用到 css module 的地方少之又少。 所以后面 css module 是会被废弃掉的。

react-gm.min.css

以前 react-gm 是提供 dist 文件的，即 js 和 css。这样在开发 Station 系统的时候没有问题。

但是 MA 要求换种颜色主题，那么就需要和 bootstrap 一样，提供一个 theme.css 的文件。 要抽出这 part 需要进行改造，工作量是挺大的。

后来 react-gm 废弃了 dist 形式，直接引入 src 的 index.js 和 index.less 文件。

库的 css 怎么引进来

基于上点

// ma index.js
import 'react-gm';
import './index.less'

// ma index.less 覆盖主题色变量即完成换主题
@brand-primary: #2c9feb;

// react-gm index.js
import './index.less'

// react-gm index.less
@import "less/bootstrap.less";

浮层管理

这个话题也可以说 浮层的管理。开发者越少关心 z-index 越好，组件提供了封装。 当然就需要框架考虑的东西更多了。

层级大致是

• 正常的文档流 1
• modal 1000
• tip 9999

另外 modal 衍生出来的 Dialog 形态即对话框，要求只有一个。不能出现弹窗中有弹窗。 技术上可以做到弹窗有弹窗，但克制，不提供相应的能力。

position fixed

移动端是禁用 position:fixed 的，不过多介绍 http://efe.baidu.com/blog/mob...

vm vh rem px

我个人是比较倾向于用 px 的。因为很简单，切和 pc web 的开发习惯一致，也是大家开发网页的默认单位。无须什么转换成本，上手就来。

当然如果是设计驱动的公司，要求高保真还原设计稿，就不太一样了，会考虑用 rem 方案。 基于兼容性考虑，我们可以直接用 vm vh。http://www.w3cplus.com/css/vw...

btw，个人还觉得 rem 在执行上很麻烦，也有对 rem 不了不深的原因。

毛玻璃

场景是对话框弹起来的时候背景出现毛玻璃效果。

这里的关键是 背景的 dom 和 对话框 不能是 包含关系，然后对背景 dom 做 filter:blue(2px)。 只要管理好 对话框的 dom 即可。

另外关键是，背景 dom 什么时机设置 filter，什么时候取消 filter。 于是引入了事件。 对话框 弹起 关闭都发出事件通知到 背景 dom 即可。

框架层架构

框架层采用了 flex 布局，给了指定区域做业务，业务只需也只能关心该区域，不能干扰其他区域，如需，需要讨论商量好。

业务区域做内滚动，这 part 其实不太好，后面想重构掉。 不好的地方有，1 滚动只要指定 dom 非 document.body。 2 跟随 dom 的弹窗不好做，需要计算位置。

css3

由于浏览器的环境很良好，所以可以尝试很多 css3 的特性，也不一定是 css3，大致意思是可以用上很多高级的功能。 比如 calc、filter 等。

图标

坚决不采用 img 来做图标。 采用 iconfont ，我们的字体托管在 iconfont.cn 平台。 iconfont 只能做单色，多色等不复杂的图片。如果满足不了则考虑 css3 或者 svg 方向。