UI 组件 CSS 的自定义

[lifesinger]

今天讨论了下：#116

晚上仔细再思考了下，感觉下午达成的方案实现起来有点麻烦，不是很妥当。

方案一

方案有两种，第一种是彻底的 classPrefix 方案，如果一个组件支持皮肤，那么该组件的 class 都要以 classPrefix 开头：

<div class="{{classPrefix}}-dialog  {{classPrefix}}-dialog-focused">
    <div class="{{classPrefix}}-dialog-header"></div>
    <div class="{{classPrefix}}-dialog-content"></div>
    <div class="{{classPrefix}}-dialog-footer"></div>
</div>

classPrefix 的默认值是 ui，用户可通过 model 传入其他值来修改：

var dialog = new Dialog({
    model: {
        classPrefix: 'custom'
    }
});

这样，从 template 生成的 html 中所有 class 都会带上 classPrefix 前缀。使用者需要重新定义所有样式。

这种支持仅处理 template 的情况，倘若 root element 是已存节点，不做任何处理。

方案二

类 Google 或 YUI 的方案，默认的 class 不修改，比如 google 的都是 goog- 开头，YUI 的都是 yui3- 开头，对于我们来说，就是都以 ui- 开头，这样模板会比较干净：

<div class="ui-dialog  ui-dialog-focused">
    <div class="ui-dialog-header"></div>
    <div class="ui-dialog-content"></div>
    <div class="ui-dialog-footer"></div>
</div>

用户需要自定义样式时，可以直接覆盖，比如 .goog-toolbar-button { ... }，或者类似 YUI3 推荐的方式，在 widget 的祖先节点或 body 上，加入一个自定义的 class，比如 yui3-skin-cool, 然后 .yui3-skin-cool .yui3-slider-image { ... } 的方式来自定义样式。

方案二的好处是，无论是从 template 构建，还是 srcNode 构建，在 render 完成时，组件都可以给相关元素统一加上默认的 class，用户自定义样式时，可以继承默认的，只修改想修改的。

方案二可参考 YUI3 的例子：http://yuilibrary.com/yui/docs/slider/slider-skin.html

方案三

KISSY 里采用的叫 PrefixCls, 但只对 root element 的 class 做调整，类似：

<div class="{{prefixCls}}-dialog  {{prefixCls}}-dialog-focused">
    <div class="ks-dialog-header"></div>
    <div class="ks-dialog-content"></div>
    <div class="ks-dialog-footer"></div>
</div>

用户如果有传入 prefixCls 配置，则 root element 的相关 class 都会加上 prefixCls 前缀。默认是 ks

选择

方案一的好处是：基于模板构建的组件，不同皮肤间可以做到彻底绝缘，彼此互不影响。坏处也很明显：1）蛋疼的模板；2）无法复用任何已有皮肤的样式，必须全新写。

方案二的好处是：皮肤的自定义，由用户决定，不想用默认皮肤时，不引入就好，直接用默认的 class 重写一套就好，如果要复用，则引入默认的皮肤，再写需要覆盖的部分就好。坏处是：1）如果一个页面有同一个组件的多套皮肤，容易引起冲突（因此在实现时，都可能走捷径采取了覆盖默认 class 的策略）。

方案三暂不讨论，感觉是方案一和方案二的混合体。

还有一种方案是：

方案四

<div class="ui-dialog ui-dialog-focused {{className}}">
    <div class="ui-dialog-header"></div>
    <div class="ui-dialog-content"></div>
    <div class="ui-dialog-footer"></div>
</div>

允许用户传入一个 className, 然后会添加到 root element 上。这样也可以实现样式的完全自定义，以及只做部分覆盖。
但如果 root element 有状态时，比如 ui-dialog-focused，这种方案在 ie6 下无效，假设 className 为 cool-dialog：

.cool-dialog.ui-dialog-focused {  // 在 ie6 下不支持
   ...
}

所以得：

<div class="ui-dialog ui-dialog-focused {{className}} {{className}}-focused">
    <div class="ui-dialog-header"></div>
    <div class="ui-dialog-content"></div>
    <div class="ui-dialog-footer"></div>
</div>

也挺蛋疼的。

综合起来考虑，好像第二种方案是实现起来最简单的？也是最优的？大家再讨论下。

[Homlean]

第二种的副作用会有哪些？同一element 多次css的渲染？

[zjl594201]

我觉得组件的模版最外层应该有一个容器，这层只关心display是block或inline，从它内部开始，才是组件真正的模版，这样做的好处是有一个隔离层，可以防止内部的某些样式影响外部，比如浮动之类的，玉伯说的classPrefix，我感觉更像是皮肤的意思，也可以定义在这层上。

只是这一层不做别的，只为隔离，只为标识从它开始将出现一个组件

[lepture]

@Homlean 第 2 种的副作用：

<div class="ui-dialog">
    <div class="ui-dialog-header"></div>
</div>

写 css 时，应该写成:

.ui-dialog {
}
.ui-dialog .ui-dialog-header {
}

但是有人会写成:

.ui-dialog {
}
.ui-dialog-header {
}

另外 @lifesinger classPrefix 不是那样写的，应该是

<div class="{{classPrefix}}  {{classPrefix}}-focused">
    <div class="{{classPrefix}}-header"></div>
    <div class="{{classPrefix}}-content"></div>
    <div class="{{classPrefix}}-footer"></div>
</div>

classPrefix 可以是 ui-dialog 或者 ui-dialog2 ui-dialog3

[pizn]

第一套方案里面是否考虑一个组件里面还能写多一个组件呢？
第二套方案挺好的。alice中的"ui-"区分的是组件，"fn-"是函数，“sl-"是兼容性解决方案。组件的使用过程中，个性化难免是需要多次重置和渲染的。
第三套方案可以作为组件里面依赖另外一个组件的写法。

[popomore]

方案二

在会议上有提过方案二所遇到的问题

方案二无法支持支付宝的样式架构，支付宝的样式库是一个池，每个组件的 key 都是唯一的。如果有两个不同的 ui-dialog，那么他们不会都叫 ui-dialog，现在习惯的命名方式是 ui-dialog2。这时我们要换一套样式是无法做到的，因为 DOM 结构不变。@lepture 所说的 theme 机制，也就是同一套 DOM 结构只变化样式，现有是无法满足的。

方案二中提到的存在两套样式的情况却是可能存在，而且很麻烦。一个比较复杂的页面存在多个不同的下拉框不足为奇，都叫 ui-dropdown，只是不同的下拉框会添加别名 (如 ui-dropdown-1) 去定义样式。

srcNode 同样无法解决，因为我们不知道使用者传的 DOM 结构是怎么样的。只有一个 className 的话是无法使用原来样式的。如果可以确定使用者传的，那方案一也不会有问题。

方案一

方案一我觉得可以从两种角度看

站在使用者的角度

• 默认使用默认的样式
• 当一个页面有两个下拉框时，可直接设置classPrefix，如 ui-dropdown1, ui-dropdown2。
• 如果传的 element，那么 DOM 结构是由使用者自己控制的，爱写什么写什么。

站在开发者角度

其实这蛋疼的模版就是给组件开发者写的，如果模版能满足使用者的需求，我觉得不应该觉得麻烦。

classPrefix 我觉得是整个组件的命名，比如 ui-dialog

[Rayi]

第二种方案其实就可以了 至于玉伯你提到的可能出现的问题，应该是在开发前就要有一个规划来进行问题规避的，这也同时起到锻炼作用。

第四种方案如你所说，其实不好，一是你提到的情况，二是如果是一些有hover状态的样式，那么可能要考虑到的样式情况就更多了，复杂度可能还超过方案二。

方案三完全不考虑，坏处都被用到了。。

[pierrewrs]

第二种方案是不是应该再拆开啊 它的第二部分和第三种方案的思路相同啊 不过后者更适应模板渲染DOM；
总之感觉应该尽量少用覆盖方式进行样式定义，要不提供空骨架让各个皮肤去自行实现（即Alice的思路），要不就是通过添加祖先元素的样式做控制，增加相应的祖子自定义规则实现新的样式效果。

[sunhunn]

我们用的类似于第二套方案，首先固定好基础结构和样式名称（写进规范不当前版本不做修改）。需要自定义样式在外层框架上添加class,简单点就是下面这样

<div class="mod xxx">
    <div class="hd"></div>
    <div class="bd"></div>
    <div class="ft"></div>
</div>

.xxx .hd{}...
对于公司稳定项目这种方式挺适合。在有规范的前提下结构和基础样式相对还是比较固定和有共性。

[popomore]

暂时选方案二，但也可以用方案一，完善文档

[lifesinger]

需进一步整理到 Wiki 中

[popomore]

已整理到 wiki

UI 组件自定义样式