是否记得这样的试题?用一套同样的HTML结构,生成不同 的视觉效果。CSS 的最大好处就是,灵活。比如同样的HTML结构,可以实现不同的外观;又比如,同样的外观,可以用不同的方式不实现。但灵活的同时也给我们带来麻烦。团队 协作时,大家的编码风格各异,其他人要看懂/debug的成本也因此提高。这时,我们需要一个规范,一个像红灯亮起我们就不能擅闯的规范。
在 Alipay 前端,Alice 框架有这样一套规范,让大家的协作更方便。这套规范基于 Alice,属于 Alice 的一部分。其最基本的原则是,同样的结构,产出不同的视觉效果。
注:所有样式的创建,都必须基于 CSS 规范 进行
http://blog.csdn.net/shoyer/article/details/8300442
一、Alice 设计模式
Alice 的设计起源于支付宝的 pa.css 文件。由于这个文件被多系统引用,没有人敢随便改动里面的内容,所以只能不断往里面添加内容,导致了这个文件体积变得非常大。所以,亟待重构。在尝试重构后,发现了重构不是我们真正想要的,因些主要从两个方面来构建 Alice:
- 减少依赖,避免耦合
- 统一风格,让代码有规可循,保证团队协作效率
更我的设计思想,请参考:支付宝CSS架构
二、关于 Alice v3
检出 Alice 前端解决方案的所有代码:
- 到 Github 上 fork 我们:https://github.com/sofish/Alice
- 直接 clone 下来:
- git clone git@github.com:sofish/Alice.git
1. 文件结构:
- ---
- |---- plugins/ 浏览器兼容解决方案对应的编辑器插件
- |---- solutions/ 浏览器兼容解决方案
- |---- tpl/ 参考的模板文件
- |---- w3c/ HTML5/CSS3 标准文档
- |---- base.css Alice 的基础,所有样式均基于它
- |---- readme.md
2. base.css 的作用
- CSS reset
- 小功能:
- .fn-clear 清除浮动
- .fn-hide/.fn-show 相当于display:block;/display:none;
- .fn-left/.fn-right 相当于 float:left;/float:right;
3. 命名规范:
注意:非组件/解决方案,请不要使用.ui-/.sl-作为前缀
- .ui- 组件前缀
- .sl- 兼容解决方案前缀
4. 注释:以一个组件结构为例
- /*
- * @name: ui-组件名
- * @overview: 组件描述
- * @required: 与其他组件的依赖关系,一般为null
- */
- /* 一般模块注释
- 一般单行或块状注释
- 注明 overwrite 的是可以覆的,没注明的是必须的
- */
- .ui-someuiorsl{
- display:block;
- overflow:hidden;
- 999px;/* overwrite */
- }
三、如何使用
1. 如何使用 alice 构建系统样式
A. 分析视觉稿
虽然视觉稿是多变的,但 Alice 模块的结构是不变的。因此,我们拿到视觉稿的第一时间(交互白板的时候,其实已经可以开始寻找),就是分析视觉稿。确认哪些资源是我们相要的。而 Alice 方面,我们要分析的是,全局设置的有那些,可以使用 Alice 模块的有哪些。通常,需要确定的全局设置包括:
- 颜色:文字、边框、背景
- 字体:种类、大小
- 布局:模块、分栏
- 图标:.ui-icon .ui-icon-NAME
一般,我们为全局设置创建一个单独的 global.css
而那些应该做为组件?一般情况下 TPL(下详)中的 14 个通用组件是必要的。另外需要根据页面使用的实际情况抽象。越多的组件,我们的编码就越统一、能创建越多的代码片段,这无论是对我们的协作,还是效率的提 升,都是非常有益的。下面这个 CheckList 可以作为你规范样式库的参考:
至于如何规划一个 CSS 文件,请参考《CSS 规范》
B. 使用tpl.css / tpl.html (命名规范在下面)
tpl.css 是一套 CSS 模板。如果你要构建新的组件。那么,你可以直接使用它。而不是引入+覆盖她。TPL 中包括了,全局设置/ 布局 / 列表 / 标题 / 切换 / 表单 / 表格 / 按钮 / 对话框。从 checklist 中可以看出已有组件列表。如果你的组件是已经有的,那么,参照已有的结构去构建。如果你新建一个新的组件,那么,使用下图所示的方法来构建:
记住:
不同外观的相同组件,HTML不要相互嵌套,CSS 推荐嵌套。
推荐的:
- <ul class="ui-nav">
- <li class="ui-nav-item"> some text
- <ul class="ui-nav-item-child">
- <li> some text
- <ul class="ui-list">
- <li class="ui-list-item"> some text</li>
- </ul...
- </ul>
- </li>
- <li...
- </ul>
不推荐的:
- <ul class="ui-nav">
- <li class="ui-nav-item"> some text
- <ul class="ui-nav-item-child">
- <li> some text
- <ul class="ui-nav">
- <li class="ui-nav-item"> some text </li>
- </ul...
- </ul>
- </li>
- <li...
- </ul>
推荐的:
- /* global scrope */
- .ui-icon-rarr{background:...}
- .ui-icon-larr{background:...}
- .ui-title{font-size:...}
- /* component only */
- <strong>.ui-nav .ui-list</strong>{...}
- <strong>.ui-table .ui-list</strong>{...}
不推荐的:(除非需要重用)
- /* set everything into a global scrope */
- .ui-icon-rarr{background:...}
- .ui-icon-larr{background:...}
- .ui-title{font-size:...}
- .ui-list{}
- .ui-nav{}
在模块化和命名上,以一个Tab组件为例,分解如下:
值得注意的是:
- 组件名是必选的
- 状态请参照下文中“状态的规范”
- 在组件窗口最外一层添加状态,而非给每一个内容添加状态。除非内容有独立的状态
比如,我们可以这样写:
- <div class="ui-new ui-new-hover">
- <h3>TITLE</h3>
- <p class="ui-new-cnt">
- ....
- </p>
- </div>
但不要这样写:
- <div class="ui-new">
- <h3 class="ui-new-title-hover">TITLE</h3>
- <p class="ui-new-cnt ui-new-cnt-hover">
- ....
- </p>
- </div>
- 直接使用 TPL,而不是覆盖 TPL
- 充分考虑组件标签的语义化和层级的灵活性
语义化是什么?什么样的写法才是正确的。这里给一个建议,把你将要构建的页面当成一本书。是段落的,你就用P(aragraph);是标题的,就用 H(eader);是引用的,就用Blockquote。而不是简单的,块状的东西由块状元素包含,行内的元素用行内的标签包含。这里有点要求就是, 去深入了解每个 HTML 标签的用法。关于灵活。像 “在组件窗口最外一层添加状态,而非给每一个内容添加状态。除非内容有独立的状态” 就是一种灵活的表现。让你更灵活去地改变状态。
关于 HTML 的语义化,可以参考:这样去写你的 HTML
2. 如何使用 style lib (系统样式)
- 已有组件:直接使用
- 组件有更改:与和系统 owner 确认,并经过全面测试,才能修改组件
- 新样式:基于 Alice TPL,创建新样式
3. Alice 组件命名规范 (参照图示)
- 组件名
尽量让人看到名字就能知道是什么组件,比较 ui-tab,比如 ui-nav 这样的命名。所有小图标都使用 .ui-icon .ui-icon- 前缀,建议同一系统(域)人的常用小图标全部合成 sprite。用 HTML ENTRY 来引用,不要写空标签,应使用 HTML ENTRY 来替代,以达到语义化的要求。HTML ENTRY 请参考这个文档:https://docs.google.com/Doc?docid=0AWiI12yCmwaoZGNiemJqOGpfMTVmaHZtOWNkeg
- 组件整体状态 = 组件名 + 状态
常用的状态有:hover, current, selected, disabled, focus, blur, checked, success, error 等。通常你的命名应该看起来像 .ui-name-hover, .ui-name-error 这样。
- 组件模块 = 组件名 + 模块名
常用模块名有:cnt(content), hd(header), text(txt), img(images/pic),item, cell 等,只要词义表达了组件要实现的功能或者要表现出来的的外观就可以了。
- 组件模块状态 = 组件模块 + 状态
参照常用状态
命名注意:
- 组件嵌套:大组件可有子组件命名。
拿支付宝某项目中的的 .ui-nav 为例,如果有多级,可以这样命名:
- ui-nav > ui-subnav(ui-nav的子类) > ui-list(嵌套进去的其他组件)
- <ul class="ui-nav">
- <li class="ui-nav-item">
- <a href="#">nav Triggle Link</a>
- <ul class="ui-subnav">
- <li class="ui-subnav-item">
- <a href="#">subNav Triggle Link</a>
- <ul class="ui-list" ....
- 多状态:多状态时,用唯一的命名来代替,而非抽象名词。
拿 ui-button 为例:
- ui-button ui-button-1pxcorner [, ui-button-indexsign [, ui-button-SOMEID]]
而不要用 ui-button-round,这样,就可能会有: ui-button-round-a ui-button-round-b … 了。按钮又有多个状态,命名就会太长了 ui-button-round-a-disabled
- 统一:
比如你比较喜欢 ui-tip-container ,另外的一个相同作用的地方,就不要写 ui-message-cnt 了,用 [ui-tip-container ui-message-container] 或 [ui-tip-cnt ui-messages-cnt] 这样会是更好的选择
- 关于 .ui-icon-方向
一般情况下,我们经常遇到方向需要用单独标签来作为小图标的例子。比如几乎每个系统都会有的 ui-message 和 ui-tip,都可能会有上下两个部分。推荐这样写:
- CLASS SPELL HTML ENTRIES
- ----------------------------------------------------
- .ui-icon-uarr Upward Arrow ↑
- .ui-icon-darr Downtward Arrow ↓
- .ui-icon-rarr Rightward Arrow →
- .ui-icon-larr Leftward Arrow ←
四、样式库维护
1. 目录结构
注:目前支付宝使用的样式库管理工具是架构组开发的一套 Maven 解决方案。
你的团队可能不止一个样式库,像支付宝,有`我的支付宝`、`生活助手`和`商家服务`等产品,所以需要根据样式库规范创建不同的样式库。样式库可以是 svn 中的一个代码目录。每个组件的 css 组件都应该有对应的 html demo。当然,如果有对应的预览截图,并形成一个展示平台,那就更好了。下面是代码目录和形成的展示平台。
- - system
- - systemName
- - resource
- - demo ----------------------> 组件静态demo目录
- - ui-xxx.html ----------------------> 单个组件静态demo源文件
- - ui-xxx.html
- - thumb ----------------------> 组件截图目录
- - ui-xxx.png ----------------------> 单个组件截图
- - ui-xxx.png
- - global.css ----------------------> 系统全局样式
- - ui-xxx.css ----------------------> 单个组件样式源文件
- ... ---------------------->
- - index.html ----------------------> 系统组件库首页
- - systemName2
- ...
像 Alice solutions 的每个组件下,都有一个 Readme.md 说明文档,查看这个范例页面:
https://github.com/sofish/Alice/tree/master/solutions/rotate
2. 打包工具
推荐使用 YUI Compressor 来压缩你的样式。目前支付宝使用的 Maven 解决方案中,集成的压缩工具就是 YUI Compressor。下载和使用文档请看这里:http://developer.yahoo.com/yui/compressor/。这里不再做细述。
关于 YUI Compressor 压缩版本的注释:
如果有些注释不想在压缩的时候删除,可以使用标识符来告诉程序,标识符是一个感叹号 “!”,示例如下:
/*! 这是不会被压缩掉的注释 */ –> /*!这是不会被压缩掉的注释*/
但像 /*中文*/ 这样的注释,如果没有空格把注释隔开可能有问题。所以,当你不想格式化注释,并希望上线的话,请确保注释是英文的,或者有空格把之隔开的中文注释。一般的 hack 注释是不会被压缩的,如:
压缩前:
- html > body p {
- color: blue;
- }
压缩后:
- html> body p{color:blue}
3. 展示平台
可以根据团队需求,构建自身的展示平台。
4. 测试规则
组件应经过严格测试。测试规则详见:《CSS 规范》
五、Alice 解决方案
解决方案的规范,同组件。不同的是:
- 解决方案要实现的是兼容,实现通常需要各种 trick,它是一种手段;而组件则是一个用各种手段实现出来的结果
- 解决方案的通用是指,偏向于指功能的通用;而组件则指视觉效果的通用
解决方案(solution)详见:http://aliceui.com/category/solutions/