• WapReview：Mobilists 移动嘉年华 209期

  导读：这是跟我的[好文推荐]非常相似的一个周期性的移动领域专题分享活动（脸皮厚一把XD），由mobili发起，人家现在已经搞到了209期，这次轮到WAPReview主办。这篇嘉年华专题中汇集了很多含金量非常高的文章链接，推荐关注。真是帅呆了~♥

资讯动态：

• macnn：未来iPhone 3G固件将原生支持地理位置共享

  导读：拨号时，屏幕上会添加一个新按钮，为发送或接受地理位置提供选项设置。详情见示意图。

• WhatMobile：Symbian完成最大的开源移植项目，承诺完全公开

  导读：超过330万台设备的平台，现在是完全开放的了！开发人员现在可以下载所有的108个源代码软件包

• SMH：Google的Tablet向iPad发起挑战

  导读：Google的Tablet，将基于Chrome OS。Google的UI设计师Glen Murphy发布了该Tablet的Mockup和交互方面的视频。

• Daily World Buzz：Apple发布iPhone OS 3.1.3
• TUAW：Skype 3G 即将更新
• iMobile：今年30款OPhone手机面世 将开放UI/UE设计
• iMobile：扩大移动导航市场 诺基亚Ovi免费地图界面赏

统计/趋势：

• sina：1月份最受关注的8款手机
• cnnic互联网研究：看手机上网的终端竞争
• iMobile：09年全球智能手机市场排名 iPhone销量翻倍

前端开发：

• nroberts：iPhone上的触摸和手势

  导读：介绍iPhone上的Touch事件API：touchstart、touchend、touchmove、touchcancel及其他。

• PPK:Touch动作研究
• PPK:持久触摸的事件对象

  导读：以上两篇都是PPK近期对Touch事件进行细致的研究成果，值得花时间仔细拜读。另外，最近的一篇“Do we need touch events”是对Touch事件和传统Mouse事件的对比和深入思考。

用户体验：

• LittleSpringsDesign：你是否正在浪费移动广告的投入？

  导读：从移动设备特性的角度，简述移动WEB广告应该具备的特性，以及一个好广告所需的用户体验。

浏览器：

• iMaemo：Mozilla Weave 1.0，无缝衔接你的移动、桌面浏览体验
• WAPReview：N900 MicroB预示了移动浏览的未来

  导读：N900 MicroB的丰富浏览体验，某种意义上代表了下一代的移动浏览标准。

• UCWEB：手机UC浏览器7.0正式版For Android
• sina：UC7.1正式版体验评测

新机评测：

• sina：金属时尚魅力 OPPO首款滑盖机A201评测
• sina：时尚更要实用 三星侧滑酷毕B5310评测

好站推荐：

温哥华2010冬奥会移动站点：http://m.nbcolympics.com

网站特点：

1. 基本符合One Web理念，全网统一的视觉识别，检测设备后URL会自动转向。
2. 通栏自适应宽度的LOGO，第一印象的视觉震撼。
3. 自适应宽度布局，尽可能满足各种屏幕尺寸的设备。
4. 留下Full Web入口，给用户自由选择权，也最大程度弥补UA适配失误或桌面用户访问错误的损失。
5. 针对iPhone进行特殊优化处理。
   1. 增大字号、间距、点击区域以便触控
   2. 增加JavaScript交互效果
   3. 优化布局
   4. 通过meta标记设置Safari的视野区域、是否全屏、状态样式等属性
   5. 通过link标记的rel=”apple-touch-icon”设置快捷图标
6. “发送给好友”功能可以直接在表单中填写好友电话号码，发送网站的URL给好友。
7. 旧标记、旧属性与CSS的搭配使用，大幅提升兼容性。例如align=”center”、clear=”all”、<b>等。
8. 模块化的代码拼装方式，有助于开发和维护的灵活性。

另外，该站点的技术支持似乎是Microsoft，感叹。

Apple iPad相关：

• iFanr：Apple 平板 iPad 概览
• ZOL：苹果iPad功能详解

Maemo & Firefox相关：

• Dennis Bournique：N900 MicroB Browser基本资料
  导读：MicroB是N900的内置浏览器，它基于Mozilla Gecko内核，基本特性非常值得关注。
• iFanr：非官方 Maemo FAQ
  导读：ifanr对Maemo系统的基础概念的FAQ，不了解这款系统的同学非常值得一看。
• Kai Hendry：Nokia N900 开发者 tips
  导读：共3篇Tips文章，针对的是N900应用程序的开发技巧和备忘。
• Dennis Bournique：Firefox Mobile RC3 For Maemo评测
• Mozilla：Firefox For Maemo 正式发布
  导读：7大特性。

新机评测：

• Jonathan Morris：Nokia X6 16GB; 更便宜、新颜色、小内存
  导读：Nokia X6是Nokia第一款触摸屏产品。
• sina：索爱3G智能新机U5i评测
• sina：黑莓新触摸屏手机 Storm 2 9520评测

其它：

• W3C：《一种可测试的一致性要求写作方法》发布。
  导读：对我们的浏览器测试报告的写法进行了统一的标准，并可利用相关接口提交生成报表。具体内容还没仔细看。
• CNNIC：3G是手机上网增长的重要因素
  导读：目前移动互联网用户已占到整体网民规模的60.7%，在中国互联网发展中将发挥越发重要的作用。CNNIC如是说。
• Jon von Tetzchner（Opera）：2009年12月份移动互联网形势报告
  导读：在Mobile WEB世界中，Twitter是发展最快的社会化网络，而Facebook是使用人数最多的社会化网络。另外，手机淘宝网排名和上月一样，依然在国内第8名。

12月中国Mobile WEB TOP10 (UV)：
1. baidu.com
2. google.cn
3. kong.net
4. sina.com.cn
5. renren.com
6. qq.com
7. soso.com (new)
8. taobao.com
9. hao123.com
10. sohu.com

• Virginia DeBolt：让你的移动站点更加友好
  导读：又是经典的设计文章，从多个角度阐述MobileWEB设计时的禁忌和技巧，值得一读。好文章是永远不会过时的。
• Simon Judge：移动开发入门
  导读：两页的PDF，针对应用程序的开发引导。偏向开发前期阶段的准备思路，随便看看就成。
• 为ePub文件格式优化图片
  导读：五梭翻译的EPUB文件优化最佳实践。Apple iBook商店中的电子书格式就是EPUB，这对以后的EPUB的设计会起到重要的参考指引作用。

好站推荐：

solmelia：http://mobile.solmelia.com/
简介：寻找和预订酒店和度假村。详情页包括介绍、全面的照片、街道地址、Email。
网站特点：

1. 界面简洁，页面视觉重点突出；单一的任务线程，过程顺畅，非常适合移动中的用户使用。
2. 流体设计，屏幕兼容范围广（176-∞）。
3. UA内容适配。桌面浏览器访问时会进行友好提示。
4. 针对Gecko、Webkit进行了CSS细节上的渐进增强处理。
5. 电话号码上 tel: 协议便于用户直接拨打电话。
6. 精美的表单细节设计，重要的提交按钮突出和放大便于点击，对次要的按钮元素进行简化设计（模拟成超链接效果）。

这是1月28日与支付宝无线组的同学们分享的PPT。非常高兴能够跟同行们一起交流和探讨Mobile Web兼容性方面的知识，认识了很多朋友，那种气氛和感觉真的很好。过去的一年，自己在分享和交流方面做得太少了，真愧对玉伯兄对我的夸奖，我想我10年知道该怎么去做了。

最后感谢沉鱼和郭威、心溪。

注意：对于本兼容性测试系列，原始测试数据将不会悉数列出，文章中只会标明需要注意的测试点（兼容性有问题或需要注意的 地方）以提供设计的参考依据。另外，这里只会针对手机内置浏览器进行测试，其它第三方浏览器（Opera Mini、UCWEB、QQ浏览器等，包括OEM版本）将不在此范围内。

[兼容性测试]Lenovo：Miro i61

（照片照得有点骚瑞，需要无码清晰大图请移步淘宝手机官方旗舰店）

基本参数信息

• 上市时间：2009
• 屏幕尺寸：3.2 英寸
• 分辨率：240×400 像素
• 颜色：26万
• 操作系统：非智能机
• 平台：MTK
• 更多参数信息

设备特色

• 触摸屏+软键盘
• 支持720p
• 屏幕左侧带有翻页键，浏览网页时可以移动焦点
• 内置UCWEB浏览器OEM版（不在本次测试范围之内）
• 内置淘宝客户端（手机旺旺、随身购、淘掌柜、支付宝、数字商店、手机彩票等，见官网）

浏览器特色

• 无太多特色
• 有标题栏，但不支持favicon
• 无指针，焦点获取式浏览
• 支持缓存
• 浏览选项非常少，只有“等待时间”和“显示图片”设置

网页兼容性测试结果

• 默认行高在1.5em左右
• 不支持disabled属性
• 不支持button元素
• 不支持input[type=file]上传组件
• 表单控件偏大，尤其是checkbox和radio
• 下拉菜单默认显示所有选项，占非常多空间
• 不支持iframe
• 不支持超链接悬停样式（无指针浏览器普遍不支持）
• 不支持字体设置
• 不支持font-variant
• 不支持line-height
• 不支持letter-spacing和word-spacing
• 不支持background缩写和background-position（支持background-color）
• 不支持position
• 不支持height
• 不支持overflow
• 不支持所有JavaScript
• 超大图片无法加载
• 页面超过20K提示内存不足，无法加载
• 额外注意：select控件遇到CSS的vertical-align时，可能会导致select大幅度浮动，并可能会覆盖其他元素

部分实际效果图

测试结果总结

问题比例（出问题的测试点占所有测试点的比例）：33%左右

一直不对MTK系统的内置浏览器报有很高期望，这款机型也是如此。XHTML中一些组件的不支持、CSS布局属性的不支持以及JS的全体不支持，会给设计留下很多的陷阱和麻烦。如果需要在这台机器上使用较复杂的布局元素和JS交互效果，要记得做好优雅降级工作。

对于网页设计来说，想伺候好这款浏览器需要重点考虑以下几点：

• 设计表单时要非常谨慎
  • 体型都很大！
  • 尤其是checkbox和radio，要注意他们接近2倍文本的体积
  • 上传组件和高级按钮要杜绝使用
  • 下拉菜单要特别加以小心，很占空间
  • 不要在表单上用disabled属性，如果某个条件下某控件不可用，那么就不要让他显示出来
• 用背景色代替背景图片，注意优雅降级
• 尽量使用流体布局，别定高，别用高级CSS布局技巧
• 别指望JavaScript实现交互
• 设计CSS Reset时，注意vertical-align的应用范围，避免应用到select上
• 注意设备自身障碍，控制图片大小、页面大小，这点非常重要

在对Mobile WEB标准支持能力不好的设备（客户端）上，优雅降级是非常重要的方法。你要时刻保持警觉，在某些细节根本表现不出来的情况下，你的页面会不会有其它的替代方案？如果没有的话，会不会影响功能的正常使用？在自身技术领域内，保证功能的正常使用是Mobile WEB前端开发的最低限度，如果因为XHTML/CSS/JS的设计失误而导致功能不可用，那么你不得不考虑换一个思路了，一般来说，总有一套方案是可以解决这些问题的。

原文分为3篇文章，我在这里进行了一些小调整，将3篇文章整理为1篇，推荐大家一口气儿读完：）

原译文地址：
http://home.blueidea.com/space.php?uid=496241&do=blog&id=11162 （第1部分）
http://home.blueidea.com/space.php?uid=496241&do=blog&id=11198 （第2部分）
http://home.blueidea.com/space.php?uid=496241&do=blog&id=12181 （第3部分）

原文地址：
http://www.w3.org/blog/MWITeam/2009/03/17/one_web_for_all （第1部分）
http://www.w3.org/blog/MWITeam/2009/03/23/one_web_for_all_part_2 （第2部分）
http://www.w3.org/blog/MWITeam/2009/04/01/one_web_for_all_part_3 （第3部分）

原作者是来自W3C MWI Team的Francois Daoust。

万网合一，One Web为人人

W3C宣传推广One Web的理念。我经常在围绕移动Web标准的讨论听到这个词，它通常出现在对移动Web最佳实践的严厉的抱怨中。是的，移动Web最佳实践标准基于One Web理念。不会采取严格限制强制设计师使用“一刀切”的行为方式。

因为One Web理念本质上被误解了，我想我应该拆穿某些神话并澄清概念：One Web理论是什么，One Web围绕什么，对于创作移动友好的Web内容意味着什么。我努力保持陈述简练，而且不会描述非常特定的细节。

你可能奇怪为什么你应该关心One Web。好，我们马上开始！

一大于二

我们思考一下以下的例子：

小明最近在维护一个网站。网站在桌面浏览器上工作的不错，但是小明最近开始收到用户的反馈 说他们用移动设备访问网站体验很不好。小明遵循移动Web最佳做法的推荐准备了一个网站的简化版本提供给移动设备。然后广告了新的版本：

• 输入 http://mingexample.org 访问普通的桌面版本
• 输入 http://mobile.mingexample.org 访问网站的移动版本

为了确保用户找到网站的移动版，他还在桌面版的首页放置了一个方便的 链接指向到移动版。

许多当今的网站都是这么干的，但是，这样通常不符合One Web理念。为什么呢？我们当然是要赞扬那些移动友好的网站开发，不是吗？但上面的例子发生问题是因为这些网站使用了两套网址（URI）。两者的差异体现 在：

• 缺失的内容：
  移动版的网站为了易于访问，通常等同于在信息量上进行大规模的裁减。移动中的用户有很多事让他们 分心，同时又想快速的浏览信息。他们确实想要适合手中设备的浏览体验，所以通常为他们传输相比桌面版来说短小的网页。但凭什么说他们想要更少的信息？用移 动设备上网不表示用户不得不这么做，而是要做他们想做的事。
• 搜索引擎：
  大部分搜索引擎用链入链接的数量来计算网页评级，然后由此排列搜索结果。评级越高，页面越容易被看 到。想链接到小明的内容的桌面版网站链向 http://mingexample.org，而移动网站们又链向了http://mobile.mingexample.org，产生两个后果：
  • 小 明的移动版网站没有继承到桌面版现有的搜索评级，对搜索引擎来说，这个移动版网站只是一个新网站，之前没有链入链接，因此很难在搜索结果中显示。
  • 链 接到小明网站的链接产生了两个不同的评级，而却不会相加，小明的网站不能获得本应拥有的搜索结果位置。
• 共享书签：
  很多用户喜欢在不同设备间共享书签和／或和使用不同设备的群体的人共享书签。小明的网站应该怎样被 收藏？没有一个权威的URI可以被所有设备使用。在桌面版首页链接到移动版是一个不错的主意，但有些设备完全不能渲染桌面版。就算它们可以，因为用户不得 不渲染一个不能正确工作的页面，所得到的用户体验也不佳。并且找到那个通往移动版的链接，用户还要花上一番时间。
• 品牌：
  广告多个URI产生令人困惑的信息，下面这个页面显示了一个小日本网站的广告，网站的访问入口取决于用 户的运营商。
  
  有研究显 示越来越多的用户喜欢在移动设备上输入他们熟悉的URI，熟悉的URI自然是桌面浏览器上输入的那个。不知道小明网站的移动版URI的用户会直接尝试输入 http://mingexample.org，他们错过了为他们量身定做的移动版。

这些问题的解决方案就是One Web。但我们先要小做一点关于Web的数学题，才能开始One Web实践。

URI的Web

万维网结构体系规范定义Web为由被称为统一资 源标识符（URI）的全球标示符标识资源的信息空间。嘿，链接去哪儿了？链接是使用全球标识符的直接结 果：Web上的任何资源可以链接到其他资源，正是因为每个资源都由全球标识符标示了。

原则：Web基于全球标识符

全球标识符可以有不同形式。在实践中则是URI。Web上的所有的链接机制都使用URI。URI是且应该被认为是标识符。它们自身并不运输任何信息。

原则：URI是不透明的

例子：

看看你的日志，你会发现一些用户尝试用只支持WML的移动设备访问你的网站。你决定为他们提供内容适配并创建一个网站的WML版本。问题是他们输入的URI 是http://example.org/index.html。不过，这样也不是问题！URI是不透明的，你尽可以用这样的URI向只支持WML的移动设备发布你的WML内容。

链接等价

Web的价值在于能将相似资源链接在一起的能力。既可以通过资源之间明确的链接，也可以通过隐含的链接（例如两个资源指向同一个资源，两个资源在搜索引擎 符合相同的关键字搜索）。Web的价值可以由资源的总价值来计算。

例子：

让我们想象一下仅包含三个资源的Web：A、B和C。资源B和C链 接到资源A。状况如下图标示。

资源B和C由于它们都链接到资源A，因此它们得到了价值，我们定义为1。资源A 因为由两个不同的链接指向，有价值的资源B和C。相加，资源A的价值就是4。这个例子的Web总价值就是6。

web的总价值在资源删除或分割后会降低。它们会发生在：

• 资源被不是URI的全球标示符识别时；
• 一个单 独的URI标示超过一个的资源；
• 资源的URI改变了；
• 资源包含的信息改变了；
• 不同的URI用来标 示相同的内容。

资源被不是URI的全球标示符识别时，相当于创建另一个web并将资源分割成不能相互通讯的不同信息空间。

好做法： 使用URI标示资源

一个单独的URI标示超过一个的资源。被URI标示的资源只被链接到可见的URI，其他的资源被隐藏了。

好做法： 使用不同的URI识别不同的资源

例子：

如果我们在资源A之后增加两个隐藏的资源。我们不清楚资源B和C究 竟链接的是A还是其他资源。A的价值降低了，变成了2。Web的总价值降到了4。

资源的URI改变了。当一个URI改变，使用原URI的链接则断开，降低了包含错误链接的资源的价值。

好做法：URI应该持久有效

例子：

当资源A的URI改变了，资源B和C现在什么也没链到。资源A的价 值降到了0。Web的总价值降到了2。

资源包含的信息改变了。链接仍然有效，但是却链接到错误的信息，所以价值降低了。

好做法：资源应该返回可预知的信息

并不是表示内容不能被改变。资源的实际内容可以经常改变，但是主题应该永远是相同的。

例子：

如果之前标示资源A的URI现在标示了资源D，资源B和C上的链接 就错了。资源D的价值还是0。Web的总价值降低到2。

不同的URI用来标示相同的内容。这样的问题是使用不同的URI链入的资源等于是复制了资源。

好做法：不要使用不同的URI标示同一个资源

例子：

如果资源A被两个不同的URI标示，资源B用第一个URI链接到 A，而C用第二个链接到A，资源B和C现在显然链接到了两个不同的资源A的拷贝上，互相并不相关了。它们各自的价值为0。

资源A被复制了。一个 拷贝的链接来源于B，另一个来源于C，每个拷贝的价值为1。Web的总价值则从6降到了2！

One Web不等于One Version

One Web理念很重要的一点是不表示：为所有的设备提供相同的版本。一个网站可以使用内容适配，也就是由设备性能和用户环境决定返回资源不同的版本。事实上， 内容适配明确鼓励改进设备上的用户体验。利用设备性能是移动 web最佳实践之一，而且符合One Web理念！

应该有多少个版本呢？ 1，10，100，1000？设计师当然想减少它们不得不维护的版本数量到最少，最好是一个。只要再一点点努力，用一些内容适配工具的帮助，可能就能从原 始版本生成所有的版本了。我们可以给所有人提供单一版本，令我们减少需要调整的内容吗？某些条件下，是可以的。比如W3C移动Web倡议的网站就没有使用内容适配（可能有一两个例外，就不在我们的 讨论范围内了），并且可以运行在大多数设备上。有人会说，这种网站的内容太“简单了”。目前来说，他说的没错，特定的版本都应该充分利用特定设备的特性。 下一篇回到这个主题上来。在这里我要强调的是，One Web理念在应该定义多少个网站版本上保持中立，当然应该遵循上面提到的那些好的做法。

好。现在差不多了解了One Web，这和真实世界有什么联系呢？

现在我们看看实践中的One Web：

Neo: I know One Web!

Morpheus: Show me.

统一地址空间

One Web指出，你应该使用统一的地址空间：资源的不同版本应该共享相同的URI，供桌 面浏览器、移动设备或是电视机顶盒等访问。

应该对全站的资源都使用统一地址空间，而不仅仅应用于首页。网站的结构在所有版本之间都应该保持一致。

主题一致性

One Web指出，URI应该返回可预知的结果。用户使用不同设备访问一个URI，例如从他的桌面PC和他的手机，应该感觉一样。换句话说，资源的不同版本应该 保持主题一致性。

主题一致性不意味着内容必须精确地保持相同。而是表示尽可能的合理于：

• 资源所提供的信息应该相同
• 色彩、logo、内容的布局应该相似
• 在不同设备上的功能性应该相似

简单地讲就是用户换了个设备访问时不用去想“我要找的那个信息跑哪去了？我在我笔记本电脑上看的时候它应该在这里呀！”不同版本的应该让用户一 眼就能识别“OK，就是这个。”

在你设计网页时就是开始考虑主题一致性的最佳时刻，请做到：

• 专注于你打算提供的内容或功能
• 确保符合页面中心思想的内容素材，可以容易的找到。相反，确保不是页面中心内容素材不引起用户的注意，或者删除它们以缩减页面尺寸，并且不 会发生主题不一致。
• 为设备不能访问的内容提供可替换的显示方式。
• 设定一个最小的通用标准，令所有设备都能访问。然后基于它，为特定设备增强用户体验。

基于最小的通用标准，有几种不同的方法增强用户体验：

• 使用CSS媒体类型处理移动和桌面样式
• 使用脚本，当设备不支持时能优美地降级显示
• 使用内容适配

内容适配

在开始使用内容适配为请求的设备发送适合设备性能的网页版本之前，你首先应该了解这些性能是什么。

请求的设备可以通过HTTP头信息识别，以及常用的User-Agent信息、Accept和Accept-Charset信 息。一旦被识别，设备性能可以从某种设备描述库中查询出来。现在有若干种数据库可用。

一旦知道了请求的设备的性能，就可以利用和适应这些性能。在返回的HTTP头信息中，增加一条Vary HTTP头信息，让服务器和终端之间的网关和代理明白你使用了内容适配，因此不会不正确地缓存页面提供给其他的用户代理。

例子：

如果你使用UA来适配内容，确保返回的HTTP应答中包含以 下信息：
Vary:User-Agent
缓存就知道此页面存在不同的版本，并且是由UA决定的，于是就不会不恰当的缓存。

内容适配产生额外的支出：你不得不为相同的内容维护很多个版本。因为很多设备的性能相同，使用设备分类是一个很好的方法，这样你可以将网站版本 缩减到最小。

为移动中的用户考虑

一旦你专为几个类别的设备创造了几个版本，你可能会进一步考虑大部分用户的使用环境。用户设备的性能是一方面，另一方面是用户所处于的环境，比如考 虑到这些：

• 设备连接的网络。有报告显示08年11月时，8%的美国移动用户通过wifi浏览网站。通常的移动网络特性（低带宽、高延迟、数据费 用）并不适用于wifi，所以你可能想提供一个增强的wifi版本。相反地，如果用户在漫游，数据费用又很昂贵。
• 用户的社会环境。街上 走着的用户比起躺在床上浏览的用户缺乏充足的时间，所以他们只是想正确而精确的取得信息。所以这样可能又要产生不同的版本。

一般的用户环境不能由它的请求表示出来。用户需要自己在版本之间切换。环境可以存储在cookie里，但cookie可能被禁用或不支持。所以 在这种情况下又得用特定的URI来区分不同的环境版本。

等等！这样不会违反统一地址空间规则吗？如果恰当的做就不会了：

• 维持和广告一个网页的权威的URI。这个权威的URI应该被用做书签和返回所有支持的用户环境的 网页版本。
• 确保这个规范的页面链接到其他存在的版本，即可以在页面上使用a链接标签让用户点击，也可以使用link标 签让机器（例如搜索引擎或移动浏览器）明白这个版本实际上是同一资源的不同形式。

例子：

以下HTML代码表示目前的网页是为移动（handheld）设备 定制的，还存在一个桌面（screen）版本。

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>[title]</title>
<link rel="alternate" media="handheld" href="" />
<link rel="alternate" media="screen" href="screen.html" />
</head>
<body>
[body]
</body>
</html>

总结

Neo: What did she tell you?

Morpheus: That I would find the One.

• One Web遵循万维网结构体系。
• One Web不表示一个版本！
• 尽可能使用统一地址空间。
• 网站的版本应该主题一致。
• 用户环境大于用户设备。
• 撰写内容时始终记住尽可能降低版本数量和适配的需求。
• 不同的环境有时要比不同的版本更多。

另外，对于原始测试结果的数据记录，推荐使用Excel来做全面的记录。Excel还是非常强大的，经过一段时间的原始数据积累，我们可以用计算公式来做总数、平均值等累加，另外可以生成统计报表，如下图所示，非常帅XD。

下面你看到的，是针对Alcatel：OT800的WEB兼容性测试记录。

注意：对于本兼容性测试系列，原始测试数据将不会悉数列出，文章中只会标明需要注意的测试点（兼容性有问题或需要注意的地方）以提供设计的参考依据。另外，这里只会针对手机内置浏览器进行测试，其它第三方浏览器（Opera Mini、UCWEB、QQ浏览器等）将不在此范围内。

[兼容性测试]Alcatel：OT800

基本参数信息

• 上市时间：2009
• 屏幕尺寸：2.2英寸
• 分辨率：320×240 （横屏）
• 颜色：26万
• 操作系统：非智能机
• 更多参数信息

设备特色

• QWERTY全键盘
• 横屏
• 支持多进程
• 屏幕右侧带有浏览滚轮，支持浏览时卷动页面，很方便
• 内置淘宝客户端（手机旺旺、随身购、淘掌柜、支付宝、数字商店、手机彩票等，见官网）

浏览器特色

• 有标题栏，但不支持favicon
• 无指针，焦点获取式浏览
• 网页构建模式：标准、自动换行、优化模式、纯文本（前3项未发现明显区别）
• 浏览模式：4向、双向、滚动（切换上下左右功能键的选择方式）
• 缩略图（选择后可在屏幕右侧开启整页的缩略图，标明当前浏览区域）
• 选择模式（选择后可以选择普通图片）
• 支持缓存
• 无屏幕转向功能

网页兼容性测试结果

• 默认行高在1.2em左右
• 默认h1-h4标题文本大小相同
• 不支持超链接悬停样式（无指针浏览器普遍不支持）
• 不支持字体设置
• 字号12px与14px大小相同（18px正常）
• 不支持letter-spacing
• 不支持vertical-align:bottom
• 不支持word-wrap
• 不支持overflow:auto和overflow:scroll的滚动条
• 不支持JavaScript的Event:onmouseover和onmouseout（无指针浏览器普遍不支持）
• 超大图片提供横向滚动条
• 不支持连续英文、中文符号换行（插入空格例外）
• 不支持特殊字符：‖♂ ♀

部分实际效果图

测试结果总结

问题比例（出问题的测试点占所有测试点的比例）：12%左右

可以说，这款机型的兼容性结果让我感觉很意外。在以往的测试机型中，支持情况是属于非常好的一个，对CSS和JavaScript的支持非常棒。问题比例与之相近的有moto的A1200e和Nokia的5800xm等。

需要特别说明的是，这款浏览器还支持XHTML的button元素、CSS的position:fixed、float、清浮、display:inline-block、负值边距、JS的XMLHttpRequest等，在设计时可以充分地考虑更高级的布局、JS交互等渐进增强方案。支持打开超过100K大小的页面，因为缓存的因素，打开浏览过的页面速度很快，在性能方面表现很优秀。

对于网页的设计来说，要比较好的支持这款手机内置浏览器非常容易，只需要重点考虑以下几点：

• 设计时不要使用12px与14px的字体来做不同文本的区分
• 不要把垂直向下对齐放在重要设计环节上
• 要注意连续英文和中文符号的不换行状况（尤其在用户留言处），可以用overflow:hidden避免对界面的破坏

最后，值得一提的是，在浏览页面时，屏幕右侧的滚轮键设计得非常好，页面很长的情况下可以用拇指很方便的向下滚动页面（类似鼠标中键）。而相对最明显缺陷是，没 有提供横向的屏幕转向设置，浏览时会感觉屏幕高度视野太小，不是很爽（OperaMini可以很好的解决这个问题，但不在讨论范围内）。

好文推荐的范围可能会涵盖以下几方面：

• 移动业内资讯（包括：行业动态/手机评测/运营商新闻/数据统计 等，这部分文章可能占比很高）
• 新技术应用（应用于Mobile领域的新技术）
• MobileWEB设计开发文章（这个是重点，但是可能不会很多）
• 经典文章（一些有长期参考价值的经典老文章，可能包括交互、设计、前端等领域）
• 好站推荐（一些有特色的MobileWEB站点成品）

精力有限。也许你会发现，分享的东西很杂很乱还没有归类，也许你会发现有些时候分享的东西很少、很偏、很单一或者根本没东西可分享。这都属正常情况，请谅解：）另外，考虑到英文资料会居多，我可能会对一些文章做中文的概要指引。

OK不多废话，下面是前一阶段看到的一些文章，希望会有些价值：

[Mobile好文推荐]开篇2010-1-23：

fool2fish：手机网站开发必修课系列文章（共3部分）

[一]手机浏览器：http://www.fool2fish.cn/?p=290
[二]浏览器兼容性测试：http://www.fool2fish.cn/?p=320
[三]2009总结版：http://www.fool2fish.cn/?p=324

备注：首篇推荐当然是来自沉鱼姐的系列文章^^。其中《手机浏览器》是译自维基百科Mobile Browser词条（http://en.wikipedia.org/wiki/Mobile_browser）的文章，对手机浏览器的历史和现状（国外市场）进行了很全面的讲述。《浏览器兼容性测试》对手机浏览器们的测试步骤和方法进行了介绍。重点推荐《[三]2009总结版》，这是我们经历了一年时间，对MobileWeb开发各个方面进行的提炼和总结，在手机兼容性方面的指引具有很高的参考价值。

WikiPedia：XHTML Mobile Profile

http://en.wikipedia.org/wiki/XHTML_Mobile_Profile

备注：WikiPedia上对XHTML-MP的介绍，非常简明扼要，并列出各个版本不同的支持情况。比OMA的易用性高很多：）

Brian Suda：Designing and Developing mobile web sites in the real world （part 1,2）

http://dev.opera.com/articles/view/designing-and-developing-mobile-web-site/
http://dev.opera.com/articles/view/designing-and-developing-mobile-web-site-1/

备注：又是来自Brian Suda的经典强文。通过实例来介绍建设Mobile WEB Sites的步骤和方法。

hillerliao：手机的输入方式

http://www.mindpin.com/mindmap_editor/mindmaps/14601.png

备注：一张强图，说明了手机的各种输入信息方式。

ifanr：Nexus One评测

http://www.ifanr.com/6286

pconline：诺基亚N900中文版应用分享

http://mobile.pconline.com.cn/review/1001/2016327.html

pconline：全球最薄Android手机!首派智能机A60评测

http://mobile.pconline.com.cn/review/1001/2028698.html

Cameronmoll：Mobile Web Design 系列

http://www.cameronmoll.com/archives/000398.html

备注：很古老却很实用的Mobile Web设计指南。

m-trend：Mobile Trends 2020

http://www.m-trends.org/2010/01/mobile-trends-2020.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+mtrends+%28m-trends.org%29

备注：移动行业未来十年的发展趋势预测，仅供参考，国内情况差距太大。反正，我没看完。

MWITeam：All webs in one, One Web for all 系列

http://www.w3.org/blog/MWITeam/2009/03/17/one_web_for_all

备注：W3C-MWITeam的“One Web”主题系列经典文章，值得收藏。

mmdays：虛擬與現實的結合：Augmented Reality初探

http://mmdays.com/2009/09/25/augmented-reality-for-dummies/

备注：Augmented Reality（增强现实技术）是新的无线技术应用，目前Android、iPhone等平台已经开始了应用尝试，值得关注。

PPK：A basic usability test on ten phones

http://www.quirksmode.org/blog/archives/2010/01/a_basic_usabili.html

备注：偶像PPK的10款手机的可用性测试报告（用户研究方向）。

手机新浪网小规模改版：

http://sina.cn（需要用Opera、或UA为移动设备进行浏览）

备注：3G导航区域去掉原来巨型的版本切换选择，增加很多实用链接，另外似乎增加了更多的UA判断。一直很欣赏手机新浪网的设计，赞。

好站推荐：

http://m.eat.fi
推荐理由：

1. JavaScript交互应用效果很帅
2. 优雅降级设计，不支持JavaScript的设备不会产生可用性问题
3. iPhone、Android等触屏设备用户的浏览体验非常爽
4. 页面源代码经过优化处理，将下载速度最大化
5. 移动特色应用：地理位置服务， 查找你附近的餐馆

Mobile Web下的编码设计

简介

晚上好，各位！在这篇文章中，我将努力揭开Mobile Web开发的神秘面纱，换句话说，也就是为了移动设备上的用户体验可以被接受，代码得怎么设计。我将阐述“Mobile Web”与普通网站的不同之处、可以让网站成功运行在移动设备和桌面浏览器上的基本技巧、一些Mobile Web设计中的建议和禁忌、以及大量资源 – 你可以去找到更多有用的信息。

Mobile Web和普通网站到底有何不同呢？

这是个很好的问题 – 首先，也许我们应该从“什么是Mobile Web”的问题开始。毕竟，用户用移动设备访问的Mobile Web，跟他们在家里用台式机访问的网站是独立的不同的部分。当我说“Mobile Web”时，我指的是“通过移动设备访问的网站”。

在Opera，我们全身心投入而创造出的浏览器允许你查看整个网络，不管浏览设备是否有这个能力。只要你在建立网站时，付出一点儿细心、尊敬并遵循Web标准，你就可以为所有人所有设备创建只有一个版本的网站 – 唯一的一个网站。但是，有一些例外情况 – 在某些情况下，只有分版本的网站才行得通，一会你会看到这一点。

移动领域的竞争环境并不平衡

在桌面领域，对于我们前端开发者来说，形式正在好转 – 大多数现代浏览器已经对Web标准支持的非常好了，无论是Opera、Firefox（以及其他Gecko内核浏览器）或者Safari（以及其他Webkit内核浏览器），甚至IE带给我们的痛苦都比原来少了。虽然IE6的用户群体数量仍然非常杯具，但这应该归结于大多数人封闭的使用习惯等因素。但是，移动设备领域在这方面却是不同寻常的：

• 你拥有能为“Full Web”提供支持的浏览器，像iPhone上的Opera Mobile和Safari。Opera Mobile使用了与桌面版本相同的渲染引擎，所以对标准的支持相差无几。
• 你拥有并不很爽的浏览器，例如IE，它们对Web标准仅能提供有限的支持。它们中的一部分只支持WAP（例如WinWap），另一些支持其他像CHTML或HTML-MP这样的标准（例如日本NTT DoCoMo的iMode浏览器），还有一些只支持Web标准中的有限子集（例如Netfront、Pocket IE、以及Blazer）。
• 最后，你拥有OperaMini，以及其他通过代理机制的浏览器。它主要只是作为连接用户和一个大服务器群的客户端界面。当用户提交一个URL时，客户端会让服务端查找这个页面。然后它会把页面转换成一个轻量级的二进制标记语言，将它格式化成适合移动设备查看的形式，并发送回客户端显示。这种方式的最主要优势，是可以使页面体积减少90%左右，帮助用户节省很多带宽费用。这种标记语言表明Web标准并不能很好的表现在移动设备上，因为在这种服务的方式下，OperaMini对Ajax/JavaScript某些方面将支持的不是很好 – 在这儿有更详细的解释。

注意：不要指望你的超级Ajax和DOM脚本动画网站在移动设备上会有良好表现。JavaScript在移动设备上的支持程度千差万别。时刻提供优雅降级吧。这种做法有一个例子叫做Hijax。

我们可以看到，在移动设备的跨浏览器兼容方面，你要思考的问题有很多。但是不要怕 – 我随后的建议会给你指引一个正确的方向；并且随着时间的推移，移动浏览器对标准的支持将会得到改善，届时我们前端开发者真的再也不需要为它们操心了。你问我这一切什么时候会实现？Who knows！

移动浏览器的其它限制还有那些？

当然，在移动设备上开发网站时，除了浏览器对标准的支持外，还会遇到其它更多的限制因素。设备自身的限制因素，你也不得不考虑。例如：

• 有限的控制 – 不要只假设你的用户会使用鼠标来控制页面中的一切，你也要提供键盘的选择。一些手机用户可能没有类似鼠标这样的东东，所以类似这样的结构 :hover 以及 onClick 对他们来说是没有用的（这对可用性方面也是非常重要的 – 一些残障用户可能在用手方面会有些缺陷）。为用户提供的表单设计也同样重要 – 你可能已经感受到，用手机来填写那些又臭又长的必填表单有多么不爽。为了解决这个问题，试着去把那一坨内容用下拉菜单的方式展现出来，这比等着用户一个字一个字手动输入来的更靠谱（译者注：目前国内有某些山寨机浏览器对下拉菜单的支持可能有不同程度的问题。例如基于MTK系统的联想i61，默认情况下会显示所有选项，而在某些情况下会产生变形和“漂移”，使用时需要谨慎些）。另外，给表单设置一个最有可能的初始值，也是一个好主意。
• 有限的屏幕尺寸 – 想象一下你那美妙的1024×768的设计在240×320屏幕下，或者更小的屏幕下，它的可用性会是什么样子……有一些方法可以应对这个情况 – 你可以故意把页面设计的很简洁流畅，或者你可以通过采取功能检测或媒体类型检测（诸如此类）的手段，为移动设备提供不同的页面。另外对于屏幕尺寸，有些手机可能不需要这么麻烦，它们可能会提供“缩放模式”这样的机制，但是你却不能保证这一点。
• 有限的内存和带宽 – 移动设备所提供的可用内存明显比台式机少得多。因此，在你设计站点时，需要特别小心的考虑那些超大容量的相册图片，以及交互式流媒体视频的应用程序。此外，一些移动浏览器提供了关闭图像显示的选项，但是你也同样不能确定这一点。
• 有限的排版 – 我靠，你对台式机上那些排版非常痴情？你没有看到移动设备上的表现！虽然这条规则有很多例外情况，但大多数移动设备对字体的选择非常有限，只有一两种（like 1 or 2）。这个限制是由系统或浏览器决定的。
• 有限的颜色 – 一些移动设备在颜色方面的支持也非常有限。考虑你有多少页面的体验需要依赖于颜色，并确认那些对比色在移动设备上仍然支持。

这些限制因素，就是导致Mobile Web的体验与PC Web的体验不同之处的真正原因。千万别欺骗自己，觉得自己的网站在移动设备上的用户体验与台式机上会保持一致 – 这纯属YY。当然，你抛开浏览器，千方百计去确认用户体验这一点仍然值得肯定。

真正的办法，去确保你的网站为移动用户提供一个良好的体验，是测试，测试，再测试！一些Web设计师们已经认识到，除了他们自己的手机、台式机以及游戏机浏览器外，还需要有一大堆移动设备需要准备在手头。

解决问题的不同方法

人们普遍意识到，有三种办法可以解决移动开发的问题（已经被Cameron Moll证实了 – 找他的书看看）。可能的话，我建议你试试这三种方式 – 如前所述，在Opera，我们坚持相信One Web的理念 – 但是刚才我也说过，有些情况下这是很难实现的，或者也是没有必要的。下面是这三种方法：

1. 务必坚持遵循Web标准
2. 创建一个完全独立的移动网站
3. 只创建一个站点(One Web)，但是根据浏览它的设备和浏览器情况，添加优化代码。

现在，让我们开始对这些点逐个讲解。

坚持遵循Web标准和最佳实践

一个好网站的基础，是要有一个好的HTML结构，以及美妙的CSS（表现）和JavaScript（行为）。如果你认真地遵循Web标准，大多数移动浏览器至少会很好地解析并至少会基本可用，这是非常有可能的。例如：

• 一个网站，有良好的HTML结构顺序并在HTML中没有装饰性图片，在移动浏览器的单列模式或移动模式中，会呈现得很有逻辑性。
• 如果你的表单元素中含有“label”元素，浏览器将把它渲染得更有表单区域的感觉。
• 如果你给CSS和JavaScript使用了优雅降级/渐进增强技术，浏览器如果不支持、简化、忽略某些属性，这时站点的可用性几率会大大增加。

如果你花费时间精力去研究的话，在提升移动用户体验方面，还有更多事情可以去做。如果你的目标受众包括大量使用非HTML浏览器（例如支持WAP或CHTML的某些日本浏览器）用户，那么你可能不得不检测设备并提供适当的内容。

提供一个完全独立的移动网站

如前所述，我认为如果可能的话应该尽量避免使用这种方式。你可以做设备检测并自动重定向来避免给用户使用带来麻烦，但是这意味着你不得不维护两套网站。最主要的方法是通过UA嗅探来识别浏览器，或在服务端进行设备功能检测，然后再给用户提供相应的站点。在dev.opera.com，有很多优秀的文章来讲述如何实现 – 查看最后的资源部分。

但也有例外，对于完全独立的网站来讲 – 你不得不始终考虑用户体验情况。某些类型的浏览设备可能不兼容于特定的网站或者特定的功能。例如，有一个大学校园网，带有部门电话号码的搜索功能，但同时也包含了一大堆校园历史的网页。如果你想去与某人会面却找不到他们部门时，你大概会想在移动设备上使用搜索功能，但你在外出的时候也不太可能想坐下来阅读那么多的文字。

在这种情况下，你可以使用下面提到的一些技巧，来为移动设备提供网站中某个功能的一部分，或者干脆为移动设备创建一套完全独立的网站。你只需检测用户使用的设备类型并自动提供给他相应的站点，并把这个过程完全公开给用户，但是很多很多人并不愿意这个功能把他们完全限制住，所以如果你要这么做的话，就需要给用户提供一个指向完整站点的链接，用户可以自行选择是否用它来访问完整站点。

一句话警告 – 设备检测很容易被滥用。你可能经常看到一个网站的桌面版本非常牛B，而它的移动站点却非常的垃圾。因为开发者只是将移动站点放在一个非常低标准的位置上。事实上，目标受众的设备水平并不均衡，现在很多的移动浏览器都具有处理完整Web页面的能力了！你应该尽可能地让设备发挥他们最高的处理能力，并且要发挥移动设备的特别优势，比如基于位置的服务（LBS），还有 tel: 协议 – 在超链接点击时它可以让设备拨打一个电话号码。

只提供一个网站(One Web)

进行到这里时，就开始变得有趣了。你可以再次依靠服务端功能检测，但这次是在单一网站的基础上进行优化，而不是重定向到另一个独立网站。有一些手机所支持功能的数据库可以参考，例如WURFL。它是以XML文件的形式开放的，你可以在设计优化内容之前，先通过它来查询设备所支持的功能。你还可以查询移动设备的UA字符串，找出这些设备的其他细节参数，例如是否有摄像头，屏幕尺寸是多少，以及它的语言种类等信息。

在客户端，你已经得到了为移动设备而优化内容所需的两个条件 – 媒体类型（media types）和媒体查询（media queries）。

媒体类型(media types)

就像你知道的那样，你可以指定不同的CSS来实现不同的用途，例如：

<link href="main.css" type="text/css" media="screen" rel="stylesheet">
<link href="print.css" type="text/css" media="print" rel="stylesheet">
<link href="mobile.css" type="text/css" media="handheld" rel="stylesheet">

手持类的媒体类型允许你针对移动设备使用优化版的样式（例如精简的布局和排版等）。这是一个被支持得很好的机制，实现起来也很简单，但它确实有它的缺陷。就像之前所说，它经常被开发者滥用，来给网站提供一个蹩脚的最低标准布局。事实上，OperaMini最近改变了默认类型，把默认使用手持型样式表（handheld stylesheet）改为屏幕型样式表（screen stylesheet）。OperaMini可以处理大多数完整网站，因此它并不真正需要使用手持型样式表（handheld stylesheet）。如果你乐意，你可以在OperaMini的浏览器选项中手动设置回移动视图。

媒体查询(media queries)

媒体查询是CSS3的一个构想，它的用途跟条件注释非常相似 – 你可以把一大堆CSS规则封装嵌入到一个媒体查询中，然后把它应用到你的标记结构中，这一切取决于一个条件，类似“屏幕尺寸是否小于480px？”然后把代码放进去，代码类似这样：

img {
  margin: 0 0 10px 10px;
  float: right;
}

@media all and (max-width: 480px) {
  img {
    margin: 10px auto;
    float: none;
    display: block;
  }
}

你甚至可以使用多个媒体查询，像下面这样：

body {
  max-width:800px;
  font-family:georgia, serif;
}

img {
  margin:0 0 10px 10px;
  float:right;
}

.info {
  position:absolute;
  left:8000px;
}

@media all and (max-width: 480px) {
  img {
    margin:10px auto;
    float:none;
    display:block;
  }
}

@media all and (max-width: 240px) {
  img {
    display:none;
  }
  .info {
    position:static;
  }
}

OK，在这个例子中（源代码点击这里查看），浏览器中的图片在屏幕大于480px时会向右浮动，文本会环绕图片并通过外边距留出一点儿舒服的距离（另有一个信息隐藏在 p 元素中，并命名了一个 class 叫 info - 看看HTML代码）。文本流在一些小屏幕中看起来可能会有些蹩脚，因为那里没有足够的空间来让图片和定量的文本放置在同一行中，所以当屏幕小于480px时，图片就需要改变一下，让文本不再围绕在它旁边，而是用 display:block 让它们显示在不同行中。等等 – 还有更精彩的！如果屏幕非常小以至于不能有效地展示图片，那就让它们消失，然后让隐藏信息显示在图片那儿，替代那些图片显示文本描述 – 这是一种将信息传达给读者的一种另类技巧，利用它也可以为那些使用屏幕阅读器的盲人用户提供原始文本，以便他们顺利浏览网站。图1展示了三个不同的浏览视图，这是在那些支持媒体查询的浏览器中（例如Opera 9.5）表现出的不同形式。

图1：例子中三个不同的浏览模式

听起来挺好，但是有没有不足呢？好吧，目前浏览器对媒体查询的支持程度非常有限。Opera浏览器支持它们，Safari 3也可以（以及其它基于Webkit内核的现代浏览器），但是Firefox 3之前的版本并不支持，IE或其他浏览器也不支持。解决问题的方法之一，是使用媒体类型和媒体查询的组合。这种方法在我的这篇文章中做过解释。这是一种变通方案，但肯定不够理想。这点在将来应该会有所改善。

摘要总结

目前就是如此而已。我希望我的移动开发世界之旅会对各位有所帮助。我在这只是抛砖引玉，要想深入学习的话，可以查看下面这些资源。

资源

• Mobile web design book, by Cameron Moll
• Designing and developing mobile web sites in the real world — 一个实例研究 by Brian Suda
• Server-side capability detection for mobile devices by Brian Suda (包含WURFL, UA字符串等信息)
• Ajax/JavaScript support in Opera Mini 4, by me
• Kristian von Streng Hæhre’s Opera Mini request header reference
• How to serve the right content to mobile browsers, 同样by牛B的me — 包含媒体类型和媒体查询
• Creating safe media queries that work cross browser
• Web design with Opera Mobile in mind, 再一次 by me
• The WURFL homepage
• The Opera Mobile homepage
• The Opera Mini homepage

关于原作者

居住地：英国
职业：Opera 开发者事务部经理

Chris Mills是Opera的开发者事务部经理 – 他在dev.opera.com和labs.opera.com编辑并发表文章，与社区保持联系，以提高人们对Opera的认识，并收集反馈，无论何时何地，他都会将Opera软件的理念传教给其他人。工作之余，他是个非常狂热的音乐迷，享受演奏和欣赏各种各样的音乐，包括金属、Funk、爵士、民谣、Hip hop等等。他现在最主要参与的乐队叫Conquest of Steel – http://www.conquestofsteel.co.uk，非常牛B。

Mobile 1：Mobile WEB介绍

简介

Opera的WEB标准课程是关于提倡WEB最佳实践，并完整地覆盖了建立现代站点所需要的所有技能和知识点，它使我们工作和浏览的WEB站点变得更加美好。这个迷你系列展开探讨了核心的WEB标准课程文章，你应该采纳所有的技能和观念，利用他们帮助你优化网站并顺利地在移动设备（或其他另类设备）上运行。首先我会进行一些常规和特殊的思考，在移动设备上运行页面，然后去写样式、编脚本并且测试，因为他们跟Mobile WEB开发相关。

这篇文章的结构如下：

• Mobile WEB的定义
• 与Mobile WEB有关的挑战
• 移动的限制性
  • 屏幕尺寸/分辨率
  • 输入机制
  • 处理能力和可用内存
  • 可用字体和颜色
  • WEB标准的支持
• 移动的优势
  • Mobile意味着随时移动!
  • 摄像头、电话和其他硬件特性
• Mobile web技术
  • WML
  • Compact HTML
  • XHTML mobile profile
  • XHTML
• CSS 和语义标记
  • 图片替换
  • CSS颜色值
• 摘要总结
• 习题

Mobile WEB的定义

“Mobile WEB”是这样一个过度使用的词条：它已经丢失了它本来意义，更糟的是，这种现象仍然在继续并且保持着“移动”的神话，这就是“Mobile WEB”。如果你去让WEB开发人员定义”Mobile WEB”，你会得到很多不同的答案。但重要的是，确定我如何定义”Mobile WEB”，以及你应该如何讨论和思考它。

W3C一直在推动“One Web”的概念。“这就意味着，在不久的将来，不管用户使用什么样的设备，他们所看到的内容和服务都是相同的。但是，这并不是说一致的信息在跨所有平台后同样能一致地呈现。移动设备的上下文环境，例如设备的不稳定性、带宽问题和移动网络性能都会影响表现。此外，一些服务和信息更适合一个特有的用户环境。”来源：W3C Mobile最佳实践One Web页面。

为了移动设备而特别建立一个”Second Web”，与W3C的愿景相违背，它并不是我们想的”Mobile Web”。你应该尽可能地避免去针对移动设备而开发的第二个版本的网站。因为这需要更多的投资，并且会变成一个维护的噩梦。你应该在桌面和移动浏览器下建立一个用户体验说得过去的网站。

使用WEB标准和最佳实践，你不用做太多额外工作，就能够使你的站点拥有友好的移动特性。Mobile Web是商业市场份额不断扩张的角落，越来越受到企业重视。在很多国家，使用移动电话上网的用户多过电脑用户，2008年的移动电话占有率超过世界人口的50% – 大约有40亿台电话。其中10亿能够连接互联网 – 这是一个不能忽视的庞大市场。（来源：Nokia论坛）

与Mobile WEB有关的挑战

Mobile Web开发一直让很多开发者感到混乱和困难，主要是由于很多过度夸大的行业术语和条目让一些新手感觉迷惑和无所适从。比如“内容运营商”、“WAP”、“deck”，其中很多与我们真正的领域关系并不紧密。我们建立一个传统的HTML站点，只是将它们上传到我们的Web服务器空间中，仅此而已。至于用户来自美国、欧洲、亚洲或别的什么地方，是在家用56K猫还是在学校用超级光线，这些都并不重要；你网站和用户电脑之间的那些基础设备，都是一模一样的。

当我们谈论移动设备访问互联网时，这些都是不正确的。从移动运营商的角度看，不同的公司企业使用不同的移动通讯站，他们压缩数据的方式并不一样，并且信号强度、有效性也天差地别。这会直接影响设备软件自身的功能。

虽然这听起来有点吓人，你不应该让它吓唬住你。 作为一个WEB开发者或设计者，你想要你的网站在移动特性上非常友好，你所要做的只是考虑几个因素。这些限制包括编写样式、编写脚本和测试很多很多设备。你现有的开发传统站点的知识结构，其实跟建立Mobile Web站点大同小异。本文的其余部分将总结所有这些问题，给你一个大方向去考虑这个领域中的问题。之后的Mobile文章会提供更深层次的处理方式。

移动的局限性

要建立一个可以运行在大部分移动设备上的移动站点，除了要坚持和PC站点采用相同的WEB标准和最佳实践，你还需要考虑这么多设备上的额外限制。虽然移动基础设施变得越来越好，更多的设备装有WiFi，但仍然有一些问题。但愿，随着时间的流逝，下面这些问题点会被逐渐淘汰和废弃，但在未来一段时期内，这些仍然是需要重点考虑的。你必须认识到不同的移动设备间性能差别很大，在顶级的智能机领域，像iPhone、HTC Touch Diamond和Samsung Omnia（还有其他S60和基于WM的电话），在所有电话中只占有很小的比例。

屏幕尺寸/分辨率

在你小时候，你应该还记得那段时间，当你浏览一个网站，上面会有一个很小的声明“最佳浏览效果：Netscape 浏览器，640×480”。今天，我们不能不考虑更高的分辨率。移动设备上，屏幕分辨率仍然变化多端，而且这种状况看起来也不会改变。

在建设你网站的移动版本时，你如何确保你的设计兼容于各种不同的屏幕分辨率和屏幕尺寸？最简单的策略是保持简单的布局和文档流。终极的理想是保持所有的页面内容在单独一列中，并在其他元素上方，因此不管多宽或多窄的屏幕分辨率，信息始终能够简单地被包裹。你只需要测试你的设计在没有CSS和JavaScript情况下的表现即可。

使用CSS Media属性、JavaScript或meta标记，能够向指定的移动设备发送CSS而不需要服务端编程。你会在这个系列文章之后的部分学到更多这方面内容。

输入机制

移动设备跟台式机有非常不同的输入方式。在你工作中，你的台式机可能会有一个完整的QWERTY键盘、一个多键鼠标，也可能是个数位板等等。但在移动设备上，你可能只有一个数字小键盘。你没有一个完整的QWERTY键盘或鼠标设备。在移动的设备上进行操作，跟在静止的办公桌上操作，体验完全不同。

如果考虑渐进增强来建立你的站点，那么它的功能不应该依赖于任何高级输入设备，但应该便于大家使用任何形式的输入设备。

处理能力和可用内存

移动设备通常会比台式机有更少的内存。这限制了他们对JavaScript、Flash和其他技术的处理能力。这些更容易费电，并且用户体验会变慢，还会增加带宽 – 最后一点还能增加用户下载页面内容的成本（如果他们是按K付费的用户，那成本就更大了）。我们会看到，这些处理能力限制会带领Mobile Web走向XML方式而不是HTML/SGML的方式。

可用字体和颜色

在你的台式机上，您可以愉快地安装各种字体，从serif到san-serif，从symbols到wingdings，但是在移动设备上，你就不能这么爽了。一些设备只有一种“标准”等宽字体，也许还会有加粗或斜体变型。这让企业品牌做了场噩梦，更别说你所有优雅的设计，在各种字体下变得糟透了！

不仅是字体的限制，一些设备还有颜色限制，但这个问题现在很少有了 – 大多数新手机会有成千上万种颜色，单色手机现在很稀有了。

WEB标准的支持

并非所有的手机都配备了像桌面浏览器那样NB的手机浏览器。有些对一般的WEB标准如HTML、CSS和JavaScript提供了完全支持。有些只支持这些标准的某些子集，或者使用完全不同的标准（参见下一节关于WML、cHTML和XHTML-MP的讨论）。有些支持HTML，但不支持CSS或JavaScript。其他的移动浏览器，如Opera Mini，先使用一个代理服务器请求网页，优化并减少了文件大小，然后再将其发送到浏览器进行显示。

这个阶段战略是测试，测试，测试，无尽的测试，以确保你的网站在一些低级浏览器中能够优雅降级。

注：如果你手边没有可用手机，你仍旧可以使用Opera Mini模拟器来测试你的页面。

移动的优势

移动设备相比台式机甚至笔记本，存在一些优势。当你设计移动站点时，可以利用这些特性以提高移动的用户体验。

Mobile意味着随时移动!

手机（或者笔记本之类）可以跟着你到处走动，这个特点开辟了移动定位应用的新发展前景 – 这些应用可以为你所在的位置提供适当的数据，例如附近饭店的建议、交通状况、电影的时间和地点、你朋友的位置等等。当前位置可以被一些设备获取，例如通过GPS全球定位系统、WEB服务和蜂窝三角测量，并且可以通过多种方式在你的WEB应用中使用该信息，例如通过实验性的W3C地理位置API，或通过Yahoo! Fire Eagle这样的API。在这系列文章中，我将不会再谈论任何地理位置服务的话题，因为它是一个高级的主题和技术，现在让你去做为时过早。下面是跟这些技术主题相关的详细链接：

• Google Latitude
• Yahoo! Fire Eagle
• W3C Geolocation API spec
• GeoRSS: Geographically encoded objects for RSS feeds

摄像头、电话和其他硬件特性

移动设备有很多台式机所没有的硬件特性。比如下面这些最明显的：

• 摄像头：现在，买一个没有内置摄像头的手机实在是件很囧的事。最近我们发现某些硬件设备已经开放API，WEB应用已经开始和这些设备产生数据交互了。
• 电话：我们不要忘了，移动电话最主要的用途是给人打电话！使用一个鲜为人知的协议 tel: 可以让这个功能顺畅地融入到你的站点。就像你使用 mailto: 来连接一个邮件地址那样，你可以使用 tel: 去连接一个电话号码。当你点击这个链接的时候，它会自动拨号。

<a href="tel:5121234567">Phone 5121234567 to book a table</a>

注意，链接文本中也要包含这个电话号码 – 虽然看起来有点重复，因为考虑到一些浏览设备不支持 tel: 协议，比如我们的老朋友台式机。

Mobile Web 技术

你所掌握的那些建立传统WEB站点的知识，同样可以很容易的用来开发移动站点。还有一些额外的缩写和一点儿历史，可以帮助我们充分理解目前移动领域的状况和发展史。根据您的目标受众和他们使用手机的类型，你可能只需坚持标准的HTML和CSS，或者可能需要退一步采取其他不同的方式。

WML

WML代表无线标记语言，于1998年创建。在此之前，没有任何标准用于移动设备的设计。

就像Web浏览器使用HTML作为内容结构，旧的移动设备，它的浏览器使用WML – 如果你需要支持真正的旧的移动设备，你就需要去了解它。WML是基于XML（XML就像XHTML和MathML，但不是HTML）跟HTML并不是一码事。HTML是一个单独的文档，在head区放置很多元数据，在body中封装可见元素。但是对于WML来说，并不能把它想象成一个页面，而应该是一副扑克牌。一个WML文件也许会有很多页面或“卡片”被包含在里面。

下面是一个WML文件的例子：

<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
"http://www.wapforum.org/DTD/wml_1.1.xml">
<wml>
 <card id="home" title="Example Homepage">
 <p>Welcome to the Example homepage</p>
 </card>
 <card id="contact" title="Example Contact Page">
 <p>Welcome to the Example Contact page</p>
 </card>
</wml>

使用WML有一些缺点。尽管它支持脚本语言，但并不支持创建很丰富的交互应用。它是为了那些非常小屏幕和低分辨率的设备而设计的。那些旧的WML浏览器不支持像GIF、JPEG等这么普遍的图片格式；而它对应的图片格式：WBMP，只支持黑白配色方案，并且这种图片格式在主流图像处理工具中也很少被支持。WML也不能兼容其他的语言格式，所以你的站点拥有一个WML版本意味着你不得不维护俩个不同版本的网站，这无疑增加了复杂性和项目经费成本。

我们真的不建议你使用WML来建立网站 – 它真的成为了历史。对于那些又老又旧的移动设备，还有Opera Mini可以用，它几乎可以很完美地运行在基于Java的任何平台上。

Compact HTML

和WML的出现几乎同一时间，CHTML也诞生了。CHTML基于Compact HTML，是在九十年代末的HTML早期版本的一个子集。CHTML非常像HTML，而且可以在PC浏览器中浏览。看来早在1998年，他们就开始意识到维护一个网站的多个版本的困难了。

最后，CHTML在日本演化成i-mode HTML，但后来被XHTML Basic和之后的XHTML Mobile Profile取代了。俨然Compact HTML已经成为了历史，不过它也是作者对“One Web”超前意识的一次完美示范。

XHTML mobile profile

XHTML-MP是XHTML标记语言的一个子集，它跟常规的HTML非常像，但也有一些限制。了解标准的HTML会帮助你了解99%的XHTML和XHTML-MP。

XHTML-MP的历史非常有趣。在WML之后，XHTML-MP以常见的XHTML/HTML标记而受到开发工程师们青睐。W3C也决定参与进来并创建了XHTML-Basic，它跟XHTML-MP非常相似。随后，XHTML-MP 1.2发布，并在标记中加入了一些功能，与此同时XHTML-Basic 1.1版本也随即出现，与之呼应。这两个标准，在功能方面几乎可以互换。

由于XHTML-MP和XHTML-Basic都是XHTML的一个子集，他们比标准的HTML有更多限制。这样移动设备可以不必支持大量的代码，只需处理站点中使用的小量内容即可（需要关于XHTML-Basic更多的限制信息，你可以在dev.opera.com阅读David Storey关于移动标记语言的文章）。

下面的代码展示了一个XHTML-MP文档的例子（注意不同的文档类型声明）：

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.1//EN"
 "http://www.openmobilealliance.org/tech/DTD/xhtml-mobile11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
 <head>
 <title>Example Page</title>
 </head>
 <body>
 <h1>Example XHTML-MP page</h1>
 </body>
</html>

注意XHTML-MP和XHTML-Basic之间的一个微妙的不同，XHTML-Basic需要服务端支持MIME类型为“application/xhtml+xml”。这样做常常会使旧版IE无法正常解析，IE会把它当做附件进行下载或使用XML方式解析，而不是像正常页面那样打开。XHTML-MP通常使用MIME类型为“application/vnd.wap.xhtml+xml”，但也可以设置成“application/xhtml+xml”甚至是“text/html”，这样任何浏览器都可以正常解析它。

XHTML

最后，还有朴实的XHTML。这是你平凡的HTML的XML版本。如果你是一个牛B的WEB工程师，那么没有什么新鲜的东西能给你。实际上，如果你不打算创造什么疯狂的鬼点子，那么你可能已经驯服了XHTML MP/Basic了。你可以很轻松地切换文档类型声明去查看是否有验证错误。

正像我们看到的那样，所有移动设备可用的标记语言都是来自于XML家庭。其背后的想法是精简浏览器中的代码，以使那些瘦弱的移动浏览器不需要处理错误嵌套的元素和其他常见的错误标记，这样就会节省很多渲染页面时额外的系统资源。

随着越来越多的移动设备使用了其台式机产品上的渲染引擎，浏览器处理标准(X)HTML页面的能力也与日俱增。当然，如果你愿意，你可以坚持使用HTML的文档类型 – 很多移动浏览器也会支持它们；我推荐真正的XHTML文档类型，因为它有一套强制性的规则，会引导你出现更少的错误、更小的下载量以及更少的处理负担。但是这些，还是由你来决定。

CSS和语义标记

这么多年，我们开发了这么多的设计和布局的技巧来让我们的标记尽可能地实现语义化，但是这些在移动设备上却是失败的。

图片替换

一个例子是标题上的图片替换：在标题元素上使用CSS增加一个背景图片，然后移除标题中的文本，只显示背景图，这个图可能是个公司LOGO，或者是图片版的标题文字。这样做可以让设计师拥有更多的设计控制权，同时又可以保持元素中的原始文本，以便屏幕阅读器和搜索引擎的读取。

杯具的是，一些移动设备浏览器只支持一部分或完全不支持CSS标准。在为移动设备优化页面时，你通常要减少文件尺寸和HTTP请求，同时还要保证设计和功能的完备。这是非常困难的 – 不管你用哪种方式为移动浏览器优化或提升用户体验，你都会在其他方便损失一些东西。

让我们看一个简单的图片替换用例，来给你更多想法。下面的例子用了一个很Nice的蓝色渐变背景图，并证明了你想得到一个精确的LOGO和色彩的同时，又要保证不支持CSS的设备能够很语义化地表现，是多么困难的事情。

我们最终想得到图形1这样的效果。

图1：我们最终的标题，带有背景图和图片替换

这个标题的HTML代码如下：

<h1><span>ABC co.</span></h1>

我们优化这个标题的过程可能像这样：

1. 首先，在标题中定义一个默认的蓝背景颜色

h1 { background-color: blue; }

2. 然后，我们利用负值text-indent技巧来挪走ABC co.这个文字，然后用背景图来替换它。

h1 span { text-indent: -9999px; background-image('logo.png'); }

渲染后的效果如图2：

图2：我们的标题文字已经被背景图片替换了。

3. 接下来，我们可以使用渐变图片来为CSS做渐进增强。

h1 { background-color: blue; background-image: url('gradient.gif'); }

显示效果如图3：

图3：我们现在有了公司LOGO和渐变背景。

我们已经达成了我们的基本目标，但是需要记住，在PC浏览器这么棒，并不代表手机浏览器也支持的这么好。

有些浏览器不支持CSS的背景图（甚至桌面浏览器在打印时也不一定支持），因为这些，你的公司LOGO可能不会显示，而且文字也仍然在页面之外不会显示，所以标题最终看起来可能像图4：

图4：如果浏览器不支持CSS背景图，我们就看不到公司LOGO了！

其他浏览器可能对text缩进支持得很糟，所以你能看见俩个文字，很杯具 – 看图5：

图5：在一些浏览器里我们既能看见背景图又能看到默认文本

解决这问题的唯一办法就是避免使用文本缩进属性，改变结构标记，让图像变成image元素，而不是CSS背景图片属性：

<h1><img src="logo.png" alt="ABC co. Logo"/></h1>

这会像图6那样显示 – 跟我们一开始想的一样 – 只是标记不那么整洁了：

图6：使用img元素会使它支持的更好，只是标记不那么整洁了

然而，一些杯具设备甚至不能渲染背景颜色，所以你那张可以使用在任何背景色上的透明LOGO图片，就只能在白色背景上显示白色文字 – 看图7！

图7：不支持背景颜色，意味着你的图片会出现白底儿+白字儿，太可怕了！

作为最后的手段，我们会不爽地决定在LOGO图上使用纯蓝色背景而让更多的浏览器兼容，并放弃使用CSS平铺的渐变背景图 – 见图8：

图8：LOGO图片的背景颜色现在是纯蓝色，所以设备如果不支持CSS背景色，LOGO也仍然可见

虽然这并不是最优化的结构标记，但它在所有设备上的呈现效果是最一致的。在任何开发中，我们都会面临实现方案的权衡，你需要意识到这些问题，并相应地予以解决。

摘要总结

这篇文章只是对Mobile Web开发领域的一个简短介绍，包括你所需要了解的一些技术和设计障碍。我还提到了CSS、结构标记使用时的问题和一些限制因素，以及不同移动浏览器之间的特性。

所有这些不同的表现和解释，都不能被认为是BUG，这只是这些设备的特性而已。虽然手机可能不支持彩屏或者JavaScript，但相应地，电池却可以使用更长时间。当你对特定的设备进行优化时，其他设备上可能又会出别的问题。由此看来，工程师和设计师貌似永远不能实现像素级别的设计，但实际上这些设备间的不同之处却是合理的、可以接受的 – 甚至是可以预期到的。“One Web”的想法并不是指所有设备上都要严格呈现同一种样式。这个目标在台式机上都很难实现，更别说在移动设备上了。

越早接受这个特点并继续前进，你就可以越早地开发更完美的网站。从屏幕尺寸和分辨率，到内置字体和颜色，到图片和HTML的支持程度，并不是所有的手机都相同的，所以最好的办法是，呈现最好的、最灵活的、最一致的设计 – 一致并不意味着完全相同。这才是测试的关键！测试是网页开发中的重要部分，但是由于多种多样的设备和性能，在移动设备中需要特例特办。

习题

• 你应该为你的站点建立几个不同版本的Mobile Web？
• 解释渐进增强
• 移动设备支持XHTML吗？
• WML原生支持那种图片格式？
• 你如何将一个超链接标记为电话号码拨号？

关于原作者

Brian Suda是一位信息专家，目前居住在冰岛的雷克雅未克。在1990年代中期以后，他每天都花大量时间上网。最近，他一直专注于移动领域 – 怎样使更小的设备让我们每天的工作生活更加愉快。他自己的小地盘儿在suda.co.uk，在这里可以找到他过去的项目和很多疯狂的想法。