5、数据录入表单
用以录入数据的表单组件:单选框、复选框、下拉框、文本框等等。可以根据需要对这类网页原生的交互组件的默认外观进行统一的初始化。如果对交互效果要求比较高,需要设置鼠标、键盘事件与表单项进行交互时的不同样式(如 onmouseover、onclick、onfocus等)。由于IE6-对伪类选择器(hover、focus)支持不完善,制作这些效果的时候要使用脚本进行一些兼容处理。另外,还有一些填写表单时的注意事项等提示类信息,以及对录入数据进行验证出错时的错误提示信息,这些信息通常会显示在表单旁边,验证错误时还需要将出错的表单项进行高亮显示,这些样式在公用模板里都需要进行设计。
6、各类备注、报错、提示信息
包括上面提到的附加在元素旁边显示的表单填写提示及验证报错,和一些对内容进行解释的备注说明等,还有一些可能会以单独模块出现,例如用户操作成功、失败或者是登陆超时等提示信息。
7、交互UI组件:切换标签、下拉菜单和模态弹窗等
除了网页表单控件以及浏览器提供的消息组件(alert、confirm、prompt),经常还需要用到一些自定义的交互组件,例如切换标签、下拉菜单,以及考虑到易用性问题而对浏览器消息组件进行封装的模态弹窗等(例如lightbox、thickbox),可以选择最常用组件集成到公用模板中。
能够供不同专业背景的人员使用则要求:
2. 使用方便,易于自学
(1). 简单易记的命名规则
具有语义的内容是最容易理解记忆的。有一种记忆法就是使用一些有一定意义的联想来增强对陌生内容的记忆。公用模板中可以使用具有简明语义的名称来对选择符进行命名,这样,非专业做重构开发的模板使用者,不必具有专业的CSS方面的知识或者是阅读很复杂的说明文档即可从命名上对模板中的选择符的用法进行理解,掌握了其中的规律,就可以非常快速地自学以达到熟练运用。
Web标准的所谓的语义性,主要是指(X)THML标签上的语义,强调要按照标签元素最初的定义去使用他们;同时提倡要使用具有结构属性语义的标签,而避免使用具有表现语义的标签。例如使用h(n)来标识各级标题,ol用来建立一个有序列表,li来标识列表项;对于small、b、i、blink、center这类含有元素视觉表现语义的标签,则要尽量避免使用。事实上除了(X)HTML标签名上固定的语义,还可以通过一些标签自定义的属性值来增强语义。例如后来出现的微格式(Microformat),就是基于class属性值的语义性的应用。
由于id的唯一性,使用id选择符的样式在同一个页面中不能重用。为了保证定义样式的可重用性,通常需要使用类定义(class)作为选择符。在对class属性值进行语义化命名的时候,严格遵循web标准结构与表现分离准则的人可能会排斥使用表现性语义,他们认为一旦需要通过改变CSS定义来更新元素的外观,类选择符所含有的表现语义就会与它修改后的实际外观不符合。例如设置左对齐并且类命名为“textLeft”的样式,如果把CSS定义更改为右对齐,则类选择器的命名语义与它的实际内容并不符合。首先要承认这种考虑是非常细致的。但实际项目的开发往往非常复杂,要综合考虑多方面需求,很难在某一方面达到理想状态。在一个大型系统的诸多页面中,要将所有使用到样式的元素都用某个结构特征来进行描述,从我的个人经验来看这是非常伤神的一件事。这些具有细枝末节的结构语义的样式的通用性也很成问题——有些元素只是使用了相同的样式,比如相同的字体、颜色等,但他们代表的结构属性却并不相同,如果选择器全部以结构语义来进行命名,很多外观相同但结构语义不同的样式就要重复定义了。例如,我们在如下两个地方都用到了红色字体,一个是报错警示信息,一个是地方是股票上涨点数,如果全部用语义命名方式,就需要分别命名一个“error”和一个“strengthen”的类定义,并且都设置属性“color:red”,这个“color:red”就在这两个地方重复定义了。如果有一个以表现语义命名的类“cRed”并设置表现语义所对应的红色样式,就可以在这两个地方同时使用“cRed”这个类了。另外还需要强调的是,我们设计制作的是“公用样式模板”,已经是经过整体规划高度抽象化了的具有代表性的元素样式,应该保持已有CSS的稳固,在需求有变的情况下宁愿去改变(X)HTML端的选择器挂钩,而不应该随意改变CSS中已定义好的属性。在必要的地方使用表现语义进行命名也是有一定合理性的。
所以,任何固有的规则都会有两面性,需要我们根据实际情况去权衡利弊。在对可变需求有一定的预见性的情况下,灵活地打破规则书写更易维护代码这也是开发人员的一项专业素质。“遵守规范的一个重要标准,就是知道何时打破它,并大胆地打破。”不应该死守教条,这样只会画地为牢自筑樊篱。只有搁置争议,综合运用,才能在项目需求、开发成本、维护成本的多方博弈中取得均衡。