关于界面的价值观与方法论
12345678910

选择符的命名原则

2January2010

其实这个主题还蛮无聊的。因为我想来想去,选择符的命名,其实并不是那么重要。况且,对于不同的人,有不同的习惯,我在这里也没法定出什么完美的标准来号召大家都使用。

不过,规划好选择符的命名,还是有几点好处的:
1. 节约时间。不得不承认,我本人经常把10%-20%左右的时间花在斟酌选择符命名上。当然,或许这只是我个人的强迫症问题。

2. 防止冲突。虽然概率很小,但还是会遇得到这种情况:某个选择符的名字,已然被用过了,导致样式冲突。这种情况通常发生在不同尺度的样式:比如登录框和登录页,某个模块里的下拉菜单和导航栏,等等。

3. 防止冗余。其实这点就比较关键啦。如果命名冲突,换个名字就是了。但如果是前后由不同的人来写样式,很可能为了避免冲突而另起炉灶。一方面浪费人力,另一方面久而久之会产生大量被废弃或覆盖的样式:打开firebug,某个样式被不同的人在不同的样式表里覆盖了N次。这就比较糟糕了。

所以,好的命名规划,一定程度上还是比较的。一些关键的命名原则有:

1. 通用的样式,一定要规范好命名。所谓通用的样式,主要有:

    a) 页面布局:比如头部顶部啦,左侧栏右侧栏啦,负责整个页面“骨架”的一些样式。

    b) 常用布局:比如列表,田字格布局(1排5个,一共5排),标签切换(tab),翻页这种经常被网页设计所用的模块布局样式。

  上面两种,在各处的样式定义可能完全不同,但由于经常用到这些布局结构,所以可以统一命名。

    c) 通用模块:这里指的是一些“固定样式”的模块,会在全站各处出现。比如登录框、搜索框、浮动工具箱等等。

    d) 小尺度的通用样式:比如菜单激活状态,文字高亮之类的。还例如某些同学喜欢用的清除浮动的样式。
把这几种类型的样式的命名规范好,就能避免很多问题。原因是因为它们通常会在很多页面里被反复使用到,所以是最容易出现冲突和冗余的地方。

2. 页面布局、常用布局以及通用模块的样式,命名要特别。

比如对于全站导航菜单,我比较喜欢用nav(navigation,即导航)来命名,而不是menu,或是main_menu之类的。原因是,可预见的是,在某些特定的页面内,会出现“菜单”这种元素,比如分类索引页,侧栏可能会出现分类的菜单列表。那如果menu被全站导航占用,到时候就容易出问题。

同样的问题也出在“登陆框”或是“搜索框”,如果简单的用login或是search,那你到“登录页”或“搜索页”的时候,就又头疼了。我比较习惯的是用login_box和search_box。

总之呢,一些“自然而然就能想到”的名词,尽量不要用在大尺度或全站通用的样式上,一开始把它们挤占了,就会导致后来的样式命名不得不另想花样,命名的混乱就由此开始。

3. 相反,小尺度的通用样式,命名要通俗简短

其实小尺度的通用样式命名,就纯粹是一个“惯例”了。比如激活的菜单,有的人用on,有的人用now,有的人用active。你管不着别人的,只能作为一个惯例推广给团队里其他同事。但不要认为“惯例”就没约束性,如果坚持用同一个名字,到处都用,其实其他同学会潜移默化的也跟着用的。比如土豆网的视频截图模块,几年来一直被称作pack。这就是aether同学最初的发明。

下面稍微列了一下,可能用到的通用样式,后面附的英文是我个人的习惯,可以参考,也可以忽略。

页面布局:

  -页面头部:header
    -图标:logo
    -右上快捷区域:quicklinks
  -页面中部:page
    -侧栏:side column
    -主栏:main column
    -第三栏:extra column
    -区块:section
      -区块顶部:heading
      -区块中部:container
      -区块底部:footing
  -页面底部:footer
    -版权说明:copyright

常用布局:

  -田字格布局:show case
  -列表布局:list
  -标签切换:tab
  -排行榜:billboard
  -表单:post form
  -纯文字区域:text area
  -翻页:page navigation

通用模块:

  -导航栏:navigation
  -登陆框:login box
  -搜索框:search box

通用样式:

  -高亮:highlight
  -激活:active,或者on
  -清除浮动:fix,或者clear
  -图:pic
  -文:txt

自己可以根据具体情况来编写这个命名规范表。比如有些网站可能全站底部有个通用的工具栏(比如facebook),那就可以把tool box放到“通用模块”里。又比如,对于“田字格”布局,有些同学可能习惯每一行用一个框套起来,每一项再用一个框套起来,那就会衍生出“row”和“item”这样的样式,另外的做法是每一行末尾用一个空div隔开,可能需要用的是“line”或者直接就用“clear”。whatever,自己决定。

4. 选择符命名的常用方法有:

  a) 基于结构的命名:比如头部/底部,主栏/侧栏,菜单列表/菜单项,区块,按钮

  b) 基于功能的命名:登录框、搜索框、排行榜、翻页、提示(tip),等等

  c) 基于内容的命名:今日焦点(focus)、用户排行榜(top users)、评论(comments)、搜索结果(search results),等等

  d) 基于样式的命名:列表、田字格、tab、高亮、标红或加粗,等等

  e) 基于状态或行为的命名:激活、拖拽、展开,等等

我没那么教条,不去从什么“样式和结构分离”的形而上原则来规定该用什么。只是谈谈,如果在未来发生需求变动,怎样的命名会让你尽量少做改动

基本上呢,前两种——结构和功能——是最安全的。因为如果结构或功能发生巨大变化,你要做的工作就多着去了,也不在乎这个命名会改动多大了。

基于内容和样式命名,就比较危险。很可能只是将“今日焦点”改名为“最新话题”,而样式完全不变。或是新增的“分类索引”模块,设计上直接照搬“搜索结果”的排列样式。遇到这种情况,你的命名就尴尬啦。基于样式命名的危险,就更不用说了。

基于状态或行为来命名,通常发生在两种情况:1. 用作JS的钩子;2. 用作某种状态变化的样式。以我的经验,它们的问题往往不是“改动”,而是“不能改动”。一旦用了,就会一直用下去,除非相应的行为方式发生变化。对此我还没深思熟虑过,但值得提醒的就是,对它们的命名要慎重,而且,最关键的是,要将它们和其他的样式剥离开来。当然,这就不是“命名”的范畴,而是“架构”的范畴,这里就不多讲,以后再说。

最后还要特别强调的是:不管采用哪种方式命名,最忌讳的是同时基于两种方式。最常见的就是“左侧栏(left column)”,它同时基于样式和结构。还比如“顶部介绍(top intro)”,同时基于样式和内容;“频道下拉框(channel dropbox),同时基于内容和功能。这些命名,在遇到样式变动,或是新增同样式的模块时候,就会陷入尴尬。

5 最后讲一个比较棘手的问题:层叠(Cascading)。写CSS,经常会遇到层叠的情况:

    搜索
      搜索关键字
      搜索提示
      搜索结果
       搜索过滤选项

这个例子,其实还好解决:就按照各元素的内容或功能直接命名即可。之所以好解决,是因为这些元素大多是本模块(搜索)所特有的,不大可能重复。但另一种情况就比较麻烦了:表单。我举个例子:

    登录
      用户名
      密码

    注册
      用户名
      密码

类似的例子还有:blog的文章(标题、内容)和留言(标题、内容)。问题的关键在于,它们是不同的模块,包含同样内容或功能的元素。更要命的是,有时候,这些元素的样式是一致的,有时候,又有点小不同,有时候,又是迥然不同。

对于层叠的情况,有三种命名方式:

  a) 模块名和元素名绑成一个名字。比如.comment_title。

  b) 只用元素名,只对元素名定义样式。比如.keywords。

  c) 也是只用元素名,但是将选择符层叠定义,比如.login .username。

至于什么情况采用什么方式,完全在于经验。但关键要考虑的因素是:一,在其他模块中是否会出现同样的元素?二,它们在样式上有一致性吗?像“搜索关键字”这种元素,如果断定在其他模块不会有同样的元素,就大胆只用元素名吧。而“登录 用户名”和“注册 用户名”,可推断的是它们的样式有一致性,或许只是一些小不同(比如输入框宽度),那就用选择符层叠定义。而“文章标题”和“留言标题”,很明显它们在样式(甚至结构)上会有很大不同,那最好各取各的名字。

我个人呢,比较倾向于用a),即模块名和元素名绑在一起。这样可能会造成一些冗余的样式定义,但即便冗余,也有一个好处:解耦。样式各管各的,不用互相牵扯。只有对于那些特别通用的模块,我才会用c)方式,比如.list .item这样。

呼,这个无聊的主题,居然也洋洋洒洒写了这么多。其中肯定有很多漏洞,毕竟我也不能预见到所有的情况。就当是一个自我总结,供参考吧。

一些想法和一个计划

21December2009

事由Hax写的一篇blog,关于“样式类”的。难得看到他写这种浅显的主题,就认真看了一下。文末他讲了这一句:

“总之,样式类虽然不至于罪大恶极,但还是应该,也可以尽量避免的。”

这句话我同意。但我仍然要对我已经同意——同时也被那芸芸的web标准的信众同意——的话抛出个疑问:为什么要避免样式类?

标准答案自然是“结构样式分离”。所……以,为什么要分离?

话说我们当年被“感召”时,都笃信了这条“结构与样式分离”。很诡异的是,这么多信众中我始终没发现有人能站出来讲一个真正对柴米油盐有意义的理由。我试图回溯了那些曾经“感召”我的词句:

“样式表能够再恰当的地方集中一批命令,以实现某种可视效果,而不是将它们到处分散在整个文档中。比如,假设要让文档中所有的标题都显示为紫色。……然而可能又决定(或许是老板决定)将标题变为暗绿色……那么又得回到前面,修改每一个FONT标签。……”

——Eric A. Meyer《CSS权威指南(第一版)》2000年,第一章

“以前重新设计网站需要几天或者几星期,现在只需要几小时,从而减少成本和避免工作烦恼”

“支持非传统的设备,从无线设备到孩子们想象到的、可以上网的智能手机以及盲人阅读器、屏幕阅读器等残疾人士使用的设备,都不需要再争论开发特殊版本的费用”

——Jeffrey Zeldman 《网站重构》 2004年,第1章

这几句话勾勒出几点很梦幻的好处:
一,原先每处都要一一修改,现在只用改一处就好;
二,一个版本,就可以支持所有的设备;
三,构建模块,重用代码。

OK,题外话,过去的15个月里,我把咱公司的网站的样式表翻了个底朝天:重写了所有页面的CSS。鉴于此,我想我还是有权抛出这样一个观点:这些梦幻般的“好处”,都是非常,非常,非常的微不足道。我们实际工作中面临的问题要比这些复杂得多:

一,原先每处都要一一修改,现在只用改一处就好——如果老板仅仅要求把紫色的字改成绿色的话;

实际的情况是:
1. 老板需要把顶部的登陆框改到左侧栏;
2. 老板需要把一排4个变成一排5个,同时把每个的图尺寸调小;
3. 老板需要让原先的紫色的其中一部分变成绿色,而另一部分变成红色;
4. 老板需要把原来直角的边框改成圆角的。

请问,这种情况下,你样式和结构要分离到什么程度才能保证“一处修改即可”?

二,一个版本,就可以支持所有的设备——如果我们的网站需要支持手机、盲人阅读器、低版本浏览器、未来的浏览器;

而实际情况是:
1. 97%的用户使用IE,其中70%使用IE6,就别提什么未来的浏览器了
2. 我们不在乎盲人是否能打开视频网站的页面
3. 对于手机业务,我们的问题不是要不要另做个页面,而是要不要另开一家公司。

三,构建模块,重用代码——如果我们的页面可以划分成固定不变的模块,同时需要它们的N种组合方式。

而实际的情况是:
1. 只有少数样式是被超过3个页面使用的。
2. 只有极少数样式是在被其他页面使用时,完全不需要做任何适应性改动
3. 很多时候,直接把一段CSS拷贝过去,比多链一个CSS文件要划算得多,无论从性能上还是从开发上讲。

诚然,用现在的情况,来抨击老人家在2000年时宣传CSS时说的话,是很不公平的。但时过境迁,如今CSS应用的如此广泛,我们理应呼唤一些更好的价值观和方法论,来指导我们如何克服在朝圣途中所遇到的阻难和纠结。

好吧,讲了N多废话(或许漏洞百出),是想宣布俺自己的一个计划:把过去15个月的关于CSS各方面的实践经验整理成系列的笔记。因为基本上在接下来一段时间,我不大会有机会如此密集的钻研一项技术了,所以也算是为这一阶段的工作做个交代吧。

既然说出口了,为了防止极可能出现的太监现象,我粗粗的整理了一个提纲。基本上它们不会包含什么具体的实践方法,可能只是一些纯理念。它们未必是最好的实践,也未必百分百正确,能抛砖引玉就好:

1. 选择符命名方法
我个人是觉得选择符不需要有什么“规范”,尤其是在Firebug之类的工具如此方便的当下。但命名还是需要方法的,好的方法可以达到的目的:一,不用花时间起名字(这个很重要,呵呵);二,不用怕起名字重复;三,节约字符;四,避免英文不好而丢脸。

2. 大网站的CSS架构
好的架构可以带来的好处:一,避免冗余的定义;二,避免改动的风险;三,避免冗余的文件夹;四,便于更好的交接和协作。

3. 常用的CSS套路
这就纯粹是讲个人习惯了,不建议照搬。做了N多网页,就能总结出一些套路,可以很快的搭好架子铺好路,不用每次都要一字一句的从body {margin:0; padding:0 }开始。

4. Sprite技巧
也不知道sprite会流行多久。这个纯粹是sprite这一狭窄的技术的一些心得,如果你很有远见的认为sprite用不了多久就会被内联图片取代,那就随便看看吧。

5. CSS变更控制与管理
CSS好写,可改起来就有些头疼了。尤其是对于一些有洁癖的人来说,更是纠结啊纠结。我想试着总结一些经验,包含从最开始如何搭建样式,到预测可能的变更,以及应对的更改方式。

6. 前端与其他工种的协作与沟通
我之前说过,前端是集结设计与开发的重要环节,与其他工种的同学保持良好的默契与沟通,是优秀前端必备的技能。可能和前端有接洽的工种包括:UI设计、后端开发、产品经理、项目经理、测试、交互设计师、数据分析、SEO,等等。我未必讲得都对,不过我会尽量挑出遇到过的做得好的例子。

哈哈,摊子铺的有点大,我都开始害怕了。anyway,如果迟迟未能完成,或是写出来让大家觉得“也不过如此”,别怪我让你失望,就怪你自己之前期待太高吧(:P)

D2_4th

19December2009

1. 小马问,上一届D2土豆那位美女主持人能来么,淘宝的兄弟都很想念她。于是我转问丁丁意下如何,丁丁问请吃饭么?小马说没问题。于是,丁丁——传说中的黑丝姐姐——欣然前往。虽然是在睡饱美容觉以及吃饱江南驿之后在下午三点才到达会场,仍然引起了会场及时聊天大屏幕的一阵骚动。

2. 对话
@zhaozexin 小马,黑丝姐姐说你不如去年那样有咬一口滋滋冒甜水的水灵feel了,注意保养啊。
@mikko 今年结婚了

3. 我、Dex、张峰,居然都中奖了!大满贯啊~中的T恤的图案,还是俺设计的呢~~

4. 推荐大家使用人间网