WAP前端开发规范
- 格式:doc
- 大小:52.00 KB
- 文档页数:7
软件开发Web前端开发规范软件开发Web前端开发规范是指在进行Web前端开发过程中,为了统一团队的代码风格,提高代码的可读性、可维护性和可扩展性而制定的规范。
本文将从代码结构、命名规范、注释规范、HTML规范、CSS规范、JavaScript规范以及版本控制等几个方面,详细阐述Web前端开发规范的内容。
一、代码结构规范:1. 项目根目录下应包含必要的文件,如index.html、package.json 等;2. 将不同类型的文件(如HTML、CSS、JavaScript)分别放在不同的文件夹中,方便管理;3.对于大型项目,可以按照模块对文件进行进一步的组织。
二、命名规范:1. 变量、函数名使用驼峰命名法,如helloWorld;2. 类名使用帕斯卡命名法,如HelloWorld;3.常量名使用全大写字母,如PI;4. 文件名使用小写字母,多个单词使用下划线连接,如index.html。
三、注释规范:1.对于重要的函数、类、模块等,应添加详细的注释说明;2.使用单行注释(//)或多行注释(/**/)来注释代码,注释应描述清楚代码的功能和作用;3.注释应写在代码的上方或右侧,避免在代码行尾添加注释。
四、HTML规范:2.缩进使用两个空格,不使用制表符;4. 使用双引号包裹属性值,如class="container";5.避免使用行内样式,将样式写入CSS文件中。
五、CSS规范:1.代码缩进使用两个空格,不使用制表符;2. 使用中划线连接多个单词,如table-layout;3.选择器命名简洁明了,避免使用过长、复杂的名称;4.属性书写顺序应统一,比如先写布局相关的属性,再写样式相关的属性;5.使用CSS预处理器,如LESS、SASS等,提高开发效率。
六、JavaScript规范:1.使用ES6语法,提高代码的可读性和可维护性;2. 变量声明使用let或const,避免使用var;3.函数命名简洁明了,避免使用过长、复杂的名称;4.将多次使用的代码封装成函数,提高代码的复用性;5.避免使用全局变量和全局函数,减少命名冲突的可能性。
网页设计与前端开发规范1. 引言在现代的互联网时代,网页设计和前端开发是构建用户友好、响应式和高性能网站的关键要素。
为了保证团队的协作效率以及代码质量的一致性,制定并遵循一套规范变得尤为重要。
2. 设计规范2.1 色彩规范•使用品牌色或统一的配色方案来传达统一的视觉形象。
•避免过多使用饱和度高、亮度强烈的颜色,以免影响用户体验。
•使用适当的对比度来确保文本易于阅读。
2.2 标题规范•使用恰当的标题层级,清晰地传达页面结构。
•遵循适当的字体大小、样式和间距设置。
2.3 图片规范•使用合适大小和格式的图片,并通过压缩来优化加载时间。
•提供替代文本(alt text)以提高可访问性。
2.4 布局与对齐规范•使用网格系统进行布局,确保页面元素自然对齐。
•避免过多使用不必要的空白,以保持页面整洁。
2.5 响应式设计规范•采用流体布局或媒体查询来适应不同设备和屏幕尺寸。
•确保内容在小屏幕上可读,并有良好的触摸目标大小。
3. 前端开发规范3.1 HTML规范•使用语义化的HTML结构,增强可访问性和SEO效果。
•遵循正确的嵌套顺序和缩进,以提高代码可读性。
3.2 CSS规范•使用外部CSS文件或CSS预处理器来管理样式。
•避免使用行内样式和重复的样式定义。
•使用合理的类名和命名约定,以提高代码可维护性。
3.3 JavaScript规范•使用模块化开发方式,提高代码复用性和可维护性。
•遵循一致的命名风格和变量命名规则。
•引入优秀的第三方库时,注意选择轻量级且有稳定社区支持的库。
3.4 性能优化规范•对CSS和JavaScript进行压缩、合并和缓存,以减少HTTP请求。
•使用异步加载脚本、懒加载图片等技术来优化网页加载速度。
4. 结语通过遵守网页设计和前端开发规范,团队可以减少沟通成本、提高生产效率,并最终构建出用户友好、响应式和高性能的网站。
同时,持续学习新技术和关注最佳实践也是保持竞争力的重要因素。
以上就是网页设计与前端开发规范的一些要点,希望对你有所帮助。
WEB前端开发规范方案文档一、概述本文档旨在规范前端开发团队的开发流程和编码规范,以提高代码的可读性、可维护性和可扩展性。
本规范适用于Web前端开发工作,包括HTML,CSS和JavaScript等相关技术。
二、项目目录规范1.项目根目录下应包含以下文件或文件夹:- index.html:项目的入口文件;- css文件夹:存放项目的css文件;- js文件夹:存放项目的JavaScript文件;- images文件夹:存放项目的图片文件;- fonts文件夹:存放项目的字体文件;- libs文件夹:存放项目的第三方库文件;- README.md:项目的说明文档。
2.CSS文件命名规范- 使用小写字母和中划线来命名文件,如:main.css;- 使用语义化的名称来命名文件,如:reset.css;- 对于一些通用的样式文件,可以使用常见的名称,如:normalize.css。
3. JavaScript文件命名规范- 使用驼峰命名法来命名文件,如:app.js;- 使用语义化的名称来命名文件,如:utils.js;- 对于一些通用的JavaScript文件,可以使用常见的名称,如:jquery.js。
三、HTML规范2.缩进和换行- 使用两个空格的缩进来表示嵌套关系,不使用tab键;3.属性顺序- 属性应按照以下顺序书写:class、id、data-*、style、src、href、alt、title等。
四、CSS规范1.样式命名规范- 使用小写字母和中划线来命名样式,如:header-title;- 使用语义化的名称来命名样式,如:main-container;-避免使用缩写,提高代码的可读性和可维护性。
2.CSS选择器规范- 使用类选择器来选中元素,不使用id选择器,以免造成样式的耦合性和难以维护性;-避免使用通配符选择器;-避免使用嵌套选择器,以免造成样式的复杂性和性能问题。
3.代码注释规范-使用注释来说明代码的用途和作用;-使用块注释来注释一整段代码,使用行注释来注释一行代码。
前端开发规范文档
《前端开发规范文档》
前端开发规范文档是在前端开发过程中非常重要的一部分,它对于整个团队的开发效率、代码质量和项目的可维护性都起着至关重要的作用。
一个好的前端开发规范文档可以帮助团队成员在开发过程中统一标准,规范流程,减少冗余代码,提高代码的可读性和可维护性。
首先,前端开发规范文档应该包括对于项目工程目录结构的规范,包括页面代码、公共组件、样式文件、脚本文件、静态资源等的组织方式,以及统一的命名规范和命名约定。
其次,文档应该明确规范前端代码的书写格式,包括HTML、CSS、JavaScript等文件格式的编码规范,同时也应该指定统
一的代码注释规范,以及对于代码缩进、空格、换行等方面的规范。
第三,前端规范文档还应该包括对于前端开发工具和框架的规范使用说明,比如对于代码检查工具、编译打包工具、性能优化工具、版本控制工具等的使用规范。
此外,对于前端项目的测试规范、部署规范、代码 review 规
范等也应该在文档中有所体现。
在跨团队协作的情况下,还应该包括团队内部和团队间的沟通和协作规范。
总的来说,一个好的前端开发规范文档,应该是能够帮助团队
成员规范前端代码书写、提高代码质量、减少维护成本,并且能够在不同的项目中复用的文档。
团队成员在遵循规范文档的同时,也应该能够在实践中不断完善文档,以适应项目的特定需求和团队的发展。
前端开发旳流程与规范在团体不停成长旳过程中, 需要处理旳需求也在逐渐增长, 团体中组员怎样分工配合决定了开发旳效率、产品旳质量, 在这个时候我们就需要一种流程来规范、指导我们, 下面就将咱们前端组旳某些经验跟大家分享一下, 有局限性之处欢迎大家指出来。
当PRD确立下来后, 前端组旳同学们就需要做好准备, 好应对高强度旳开发工作。
在今年年初旳时候前端组通过剧烈旳讨论针对新产品旳开发做了某些约定。
制定了前端开发旳某些有关旳规范, 包括不同样产品旳命名规范, 前端文献寄存目录等等一系列旳前期准备。
别看这些只是小事, 但做好万全旳准备, 是敏捷开发中所必旳。
下面讲讲前端开发组旳流程。
1.分层开发在PRD确定后就需要进行分层开发旳划分, 根据项目内容旳不同样, 划分组员旳工作。
大体分为, 总体构造搭建、模块制作、页面制作、底层JS搭建、JS交互效果、内部测试、代码优化。
这样做旳好处是能根据项目旳不同样, 划分出不同样旳功能模块, 合理旳进行人员分派, 让合适旳人做合适旳事。
减少开发成本, 提高开发效率。
2.代码编写前期工作准备好后, 就开始进入代码编写阶段, 我们采用LSM 方式进行, 大体流程为 prototype产出后, 就进行前期旳前端开发(搭建大体旳HTML构造), 然后设计出完设计稿后再进行页面样式旳完善, 最终完毕正式旳页面后交给开发, 嵌套程序。
这样做旳好处不仅能有效旳提高开发效率, 实现逐层开发, 让前端提前介入, 减少整体消耗旳时间, 保证产品有更多旳时间修改和完善。
确定了流程后还需要对产品原型进行分析、拆分, 把复用性高旳部分找出来制作成代码模块, 以便后来旳套用。
确认二、三级页面旳风格搭建统一框架。
设计拿到prototype后, 就进行通用模块样式旳设计(包括按钮、分页、默认字体颜色、连接颜色等), 完毕后并提交给前端, 统一旳搭建。
在代码旳编写过程中, 最重要旳是原则和规范旳执行遵守, 在编写HTML时候充足发挥想象尽量旳满足后期样式体现旳需要。
前端开发设计规范文档一、引言前端开发是为用户提供良好的用户体验和友好的界面而进行的开发工作。
为了保证开发的一致性和高效性,制定前端开发设计规范是至关重要的。
本文档旨在提供一套通用的前端开发设计规范,帮助团队成员在开发过程中更好地协同工作,并提供一致美观的用户体验。
二、命名规范1.文件和目录命名规范-使用小写字母和连字符"-",不使用大写字母、空格或下划线。
-确保文件和目录名称清晰、简洁且有意义。
2.变量和函数命名规范-使用有意义的英文单词或短语命名变量和函数。
-使用小驼峰命名法,即第一个单词首字母小写,后续单词首字母大写。
-避免使用过于简单的变量名,如a、b、x、y等。
3.CSS类和ID命名规范-使用英文单词或短语命名CSS类和ID。
-使用连字符"-"分隔单词,避免使用下划线。
-避免使用过于简单的类名或ID,如a、b、c等。
三、HTML规范1.DOCTYPE声明规范- 使用 HTML5 的 DOCTYPE 声明,即 <!DOCTYPE html>。
3.属性使用规范-使用双引号""包裹属性值。
-避免使用行内样式,优先使用外部CSS文件。
四、CSS规范1.选择器使用规范-使用类选择器和ID选择器,避免使用元素选择器。
-避免使用过于复杂的选择器,保持简洁性和性能。
2.样式书写规范-使用缩进和换行使样式代码更易读。
-按照属性的字母顺序排列样式规则。
- 使用简写属性,如 margin、padding、font等。
3.文件组织规范-将样式规则分别存放在不同的CSS文件中,便于维护和管理。
五、JavaScript 规范1.变量和常量声明规范- 使用 var、let 或 const 声明变量和常量,避免使用全局变量。
-尽量将变量声明和赋值放在同一行。
2.代码书写规范-使用缩进和换行使代码更易读。
-使用驼峰命名法命名变量、函数和对象属性。
-使用分号";"结束语句。
前端开发规范一、项目1.项目名全部采用小写方式,以中划线分隔。
如:my-project-name2.目录名参照上一条规则,有复数结构时,要采用复数命名法,如:scripts, styles, images,data-models3.所有JS文件名,多个单词组成时,采用中划线连接方式,比如说:账号模型文件account-model.js4.CSS多个单词组成时,采用中划线连接方式,比如说:retina-sprites.css5.HTML文件多个单词组成时,采用中划线连接方式,比如说: error-report.html二、HTML1.缩进使用4个空格的soft tabs,可以保证代码在各种环境下显示一致。
2.嵌套的节点应该缩进。
3.在属性上,使用双引号,不要使用单引号。
4.虽然doctype不区分大小写,但是按照惯例,doctype大写。
例:<!DOCTYPE html>5.在引入CSS 和JavaScript 时不需要指明 type,因为 text/css 和 text/javascript 分别是他们的默认值。
6.根据H5规范,在引入CSS和JavaScript 时不需要指明 type,因为 text/css 和 text/javascript 分别是他们的默认值。
所以,别写多余的代码。
例:<script src="leo.js"></script>三、CSS1.缩进:老规矩,使用4个空格的soft tabs2.每条声明 : 后应该插入一个空格。
如:padding : 10px;3.每条声明只占用一行。
4.所有声明应该以分号结尾。
(包括最后一行,因为你不保证哪天你在此后面增加声明后忘记添加上分号)5.逗号分隔取值之后增加一个空格。
例:box-shadow: 0 1px 2px #ccc, inset 0 1px 0 #fff;6.所有的十六进制值都应该使用小写字母,例: #fff。
WEB前端开发规范WEB前端开发规范一、命名规范1. HTML/CSS命名规范- 使用大写字母和小写字母的组合方式,不使用汉字、拼音或其他特殊字符。
- 使用有意义的命名,能够反映元素的用途或内容。
- 使用连字符"-"作为多个单词的分隔符。
- 避免使用复数形式命名。
2. JavaScript命名规范- 使用驼峰命名法,首字母小写。
- 类名首字母要大写。
- 命名要具有表达性,能明确表达出变量或函数的用途。
3. 图片命名规范- 使用有意义的命名,能够反映图片的内容或用途。
- 使用连字符"-"作为多个单词的分隔符。
- 图片命名中不要包含特殊字符或中文。
二、代码规范1. HTML规范- 使用语义化的标签,遵循W3C标准。
- 元素属性值使用双引号包裹。
- 缩进使用两个空格,不使用TAB键。
2. CSS规范- 尽量避免使用!important。
- 属性和值之间用一个空格隔开。
- 选择器和属性名使用全小写。
- 使用缩进和换行使代码具有良好的可读性。
3. JavaScript规范- 使用ESLint进行代码检查,并遵循检查结果进行修改。
- 使用分号结束语句。
- 使用const和let替代var。
- 使用模块化开发,避免全局变量的滥用。
4. 文件目录规范- 对于大型项目,建议按照模块和功能进行文件分层。
- 文件和文件夹命名要有意义,能够清晰表达文件的用途。
5. 注释规范- 对于重要的代码块、函数和类,添加必要的注释,解释其作用和用法。
- 注释要简洁明了,不要使用口语化的表达方式。
- 避免不必要或重复的注释。
三、性能优化1. CSS性能优化- 避免使用过多的样式表和多层嵌套。
合并和压缩CSS文件。
- 使用CSS Sprites合并图片。
- 避免使用纯色背景图片,使用CSS实现。
2. JavaScript性能优化- 代码压缩和合并,减少HTTP请求。
- 合理使用缓存,避免重复请求相同的数据。
本文主要从以下几个方面来概述前端的开发规范1. 目录构建规范2. 前端命名规范3. 前端工作规范4. 开发文档的书写规范1. 前端目录构建规范我们从命名原则、根目录、业务逻辑等方面进行目录构建1.1 命名原则:- 简洁明了(如下:)* src 源代码* img 图片资源* js JavaScript脚本* dep 第三方依赖包- 不使用复数(如下:)* 不使用imgs docs1.2 根目录(root)结构按职能划分(如下:)- src 源代码(逻辑)- doc 文档- dep 第三方依赖包- test 测试1.3 根据业务逻辑进行文件夹的划分(如下:)- src目录名词解释:- common 公共资源- public/static 静态资源- component 组件- view/tpl 模板文件```srccommon 公共资源imglogo.pngsprites.pngcssreset.cssjsconf.js 项目的配置文件public/static 静态资源jscsstplindex.html shopcar.htmlimgcomponent 组件homeshopcarloginregisteruserlistdetailview/tpl 项目模板tpl 是template的缩写```1.4 总结:以上目录开发规范有两种使用途径1. 使用前端工程化工具如webpack、gulp等进行手动打造2. 利用框架提供的脚手架工具进行修改2. 前端命名规范这部分内容我从以下两个方面来进行讲解·CSS命名规范o BEM规范o OOCSS规范·javaScript编写规范o jslinto eslint2.1 css命名规范2.1.1 BEM规范- 概念:Block Element Modifier,它是一种前端命名方法,旨在帮助开发者实现模块化、可复用、高可维护性和结构化的CSS代码。
前端开发设计规范文档1.前言前端开发是构建用户界面的过程,它的设计和编写需要遵循一定的规范,以保证代码的可读性、可维护性和可扩展性。
本文档旨在提供一个前端开发的设计规范,帮助开发人员在设计和编写前端代码时遵循统一的规范。
2.命名规范2.1文件和文件夹命名-文件名使用小写字母,单词之间可以使用连字符“-”连接。
-文件夹名同样使用小写字母,单词之间使用连字符“-”连接。
2.2变量和函数命名- 变量和函数名使用驼峰命名法,即第一个单词首字母小写,后面的单词首字母大写。
例如:userInfo, getUserInfo。
2.3CSS类命名- CSS 类名使用连字符“-”连接,例如:main-container, login-button。
3.HTML规范3.2嵌套规范-HTML元素的嵌套应该保持良好的层次结构,不要过深嵌套。
-使用缩进保持结构清晰,增加代码的可读性。
4.CSS规范4.1使用外部样式表-将CSS样式写在外部样式表中,使代码可重用和维护。
4.2避免使用行内样式-避免在HTML元素上使用行内样式定义样式。
4.3样式规则的书写顺序-将样式规则按照从上到下的顺序书写,以保持结构清晰。
-先定义通用样式,再定义特定样式。
-按照样式的属性顺序书写,例如先写字体相关,再写颜色相关。
4.4使用CSS预处理器-使用CSS预处理器(如SASS或LESS)来提高CSS代码的可维护性和可扩展性。
5. JavaScript 规范5.1使用严格模式- 在 JavaScript 文件的开头添加 "use strict" 来启用严格模式。
5.2使用语义化的命名-使用有意义的变量和函数名,易于理解和维护。
5.3避免全局变量和函数-尽量避免使用全局变量和函数,以减少命名冲突和代码污染。
5.4缩进和空白符-使用合适的缩进和空白符来增加代码的可读性。
5.5注释规范-使用注释解释代码的意图和功能。
-在复杂的代码块前添加注释,帮助其他开发人员理解代码逻辑。
JAVA WAP开发那点事在看这些经验总结之前,我强烈的建议无线开发人员及产品人员熟读WML的规范,手册地址:/index-18.asp.htm根据我们长时间开发的积累,我们在使用过程中确实遇到的一些问题,通过这些积累,使得我们找到移动互联网开发的一些规律:1、我可以在屏幕上显示几行信息?事实上,对显示多少行没有特别限制,只要不超过面板的最大尺寸就行(随设备的不同而不同)。
然而,为了避免太多滚屏,每屏(即卡片)5 至 7 行最佳。
当然屏不要太多,3-4屏为极限,因为考虑到目前市场上很多的山寨手机对WML页面大小支持的不好。
2、我们应该权衡GET/POST哪些问题?在实际开发中,确实遇到一些电话不支持使用 POST 方法发送表单数据,这种情况,我们确实没有办法去做兼容了。
因为在实际开发中,有些数据我们必须要为用户保密,例如用户名和密码必须通过 POST 方法发送。
在 WAP 网关上,如果日志功能被激活并且请求已被记录,管理员就有能看到用户名和密码。
如果网关是由 ISP 或其它第三方提供的,这个问题就会特别突出。
即使一个安全的连接也不能完全消除安全隐患。
那些发送到 WAP 网关的数据使用WTLS(Wireless Transport Layer Security)加密,它使用与标准 TLS 相同的算法。
然而,发送到 WAP 网关的数据是二进制的编码格式(对 WAP),所以这些加密后的数据必须用 TLS 解密和再加密以适用于因特网。
经过一段时间以后,敏感数据在 WAP 网关上以明文的形式出现。
黑客则会在适当的时刻,将内存中的信息转储出来,进而成功地访问这些敏感数据。
按照注释,解决该问题的一种办法是在自己公司(而不是在 ISP)设一个 WAP 网关。
在这种情况下,一个可信的人可以操作网关,并且可以关闭日志功能。
您也可以用 WMLScript 来编写自定义的加密算法,以对客户端的用户名和密码进行加密。
这只有在使用简单的算法时才有可能实现;在支持 DES 类的算法上,WMLScript 不够强大。
虽然有这么多的顾虑。
我们在实际的开发中选择的依然首选的是GET。
我们建议使用GET方式提交参数,是考虑到URL可移植、保证参数完整,但是同时我们为了保密、限长度可以在合适的地方(用户保密数据、参数可能出现过长)应用POST。
3、我怎样保持 Session?我们再做任何一个模块设计的时候都不要假设手机终端都支持cookie(虽然部分手机支持cookie,但不能保证用户都开启cookie)。
这样,当用户在您的站点的不同页面之间穿梭时,为了在服务器端保留关于客户端的信息,在向服务器发送每个请求的同时,一个Session ID 必须被当作参数传递。
Session ID 的参数名根据 Servlet 引擎的不同而不同。
有时,缺省的 Session ID 长度很大幅度地增加了每个请求的长度。
结果导致客户端或 WAP 网关可能将此请求看作一个无效的 URL 而拒绝。
这样有必要缩短 Session ID 的长度。
可自定义一些所短sessionID长度的方案。
4、Select 框参数的提交?因为WAP浏览器的简陋、多而杂,在不同的浏览器里,select提交被截获的参数值也是不同的,如在select中,你选中了1/2/3提交后,截取的值,可能是1,2,3,也可能是1;2;3。
这点跟WEB上有些许差异,请大家多注意5、参数简单化?在开发过程中,我们经常是为了页面参数提交的简单,即为了减少参数的提交个数,我们喜欢在WML页面对一些参数进行拼装。
如下:<postfield name="content" value="$(bwBall)~$(swBall)~$(gwBall)"/>,实际操作中,我们应该避免这样的参数拼装,仅管在WAP1.1之后确实支持一些分割符的分隔6、编码问题同样是个诟病?无论我们在J2EE/J2SE开发过程中,都会遇到编码的问题,不同的是WML中遇到的编码问题大多数并不是我们服务端导致的,手机厂商对编码没有固定的设置,很多用户不会去关心手机的编码,在参数提交时如果带有中文参数,在参数接收时,就需要对参数进行处理,因为客户端提交过来的可以是ASCII码7、“内部服务器错误”?如果做WML开发你没遇到过这类错误,那你绝对不是一个称职的开发。
在手机中报这类错误,基本上都属于功能机,对应的 response code 是500。
8、WML页面对图片的支持度?在WML页面里,图片是不被建议的,如果非要使用的话,请注意图片不要多于5张,图片最好要经过处理,越小越好。
另外图片的格式最好是PNG,如果有条件的话PNG、GIF、JPG最好都备上。
9、转义字符的使用?在WML中,跟HDML一样,多个连续的空格只显示一个空格;在WML中,一定要注意使用转义字符,如:< ----- <> ----- >‘----- '“----- "& ----- &$ ----- $$空格----- - ----- ­特别是在URL参数传递过程中,源码中&必须写成&10、一个标准的crad?card是WML的单元,由此,我们可以知道一个WML页面可以有多个card(静态文字预加载推荐使用)。
如下是一个WML最基本的元素:<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN""/DTD/wml_1.1.xml"><wml><head><meta forua="true" http-equiv="Cache-Control" content="max-age=0"/><meta forua="true" http-equiv="Cache-Control" content="no-cache"/></head><card id="index" title="爱彩票"><p>内容</p></card></wml>11、关于WML页面的表单参数提交<anchor>?有一个标准的表单提交的实例:源码:<img src="/logo.gif" alt="Baidu"/><input name="word" size="4"/><br/><anchor>搜网页<go href="/baidu" method="get"><postfield name="word" value="$(word)"/><postfield name="tn" value="wisewml"/><postfield name="rn" value="5"/><postfield name="ie" value="unicode"/><postfield name="cl" value="2"/><postfield name="vit" value="uni"/><postfield name="from" value="578b_w1"/></go></anchor>|<anchor>进贴吧<go href="/f" method="get"><postfield name="kw" value="$(word)"/><postfield name="from" value="578b_w2"/><postfield name="inb" value="1"/></go></anchor>在这里有个很好的体现,提交文字所在的位置,这个问题,针对小部分手机会有差异(会产生页面解析失败的情况)。
我们最好的习惯是将提交文字写在<anchor>与<go href=”” method=”get”>之间。
12、WAP如何保证表现层可维护性?这可能是最可怕的事情了,由于WAP业务的特殊性,合作推广相对WAP较频繁,如果系统开发人员没有一个好的思想,好的编程习惯,喜欢将代码粘来粘去(特别是页面代码),时间长了,这将给系统带来毁灭性的结局。
13、低端机对WML标签的支持?移动终端,大家要清楚的就是这是个以简洁为主的地盘,无论从业务上还是从技术上,WEB人员都喜欢将WEB的一套模式照搬到WAP中来,如果你真的那样做的话,我要告诉你,你会死的很惨,很多WEB上的业务是跟WAP的用户群的截然不同的,那么从技术上来说,也是不能通用的。
特别是低端机,很多好的效果,好的模式都是不支持的,所以说这是个简单的平台。
举例:在html页面我们会用各种颜色,各种字体,想方设法的让展示更炫,WAP行不通的,如下标签就不能通过---一般手机会报:内容格式错误<b>粗体</b> ---------低端机不支持<i>斜体</i> ---------低端机不支持<img alt="pic" src="" /> ---------在使用img标签时,alt标签必填如果你想你的应用以展现为主,那么有些丰富页面的标签你可以尝试一下,如果你的平台是电子商务,那么我奉劝产品及开发人员,这些标签你还是离它们远点。