从观麦前端框架的角度看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 方向。