在这篇文章中，将为大家努力揭开Mobile Web开发的神秘面纱，换句话说，也就是为了移动设备上的用户体验可以被接受，代码得怎么设计。这篇文章将阐述“Mobile Web”与普通网站的不同之处、可以让网站成功运行在移动设备和桌面浏览器上的基本技巧、一些Mobile Web设计中的建议和禁忌、以及大量资源 。
Mobile Web和普通网站到底有何不同呢？
这是个很好的问题 – 首先，也许我们应该从“什么是Mobile Web”的问题开始。毕竟，用户用移动设备访问的Mobile Web，跟他们在家里用台式机访问的网站是独立的不同的部分。当我说“Mobile Web”时，我指的是“通过移动设备访问的网站”。
在Opera，我们全身心投入而创造出的浏览器允许你查看整个网络，不管浏览设备是否有这个能力。只要你在建立网站时，付出一点儿细心、尊敬并遵循 Web标准，你就可以为所有人所有设备创建只有一个版本的网站 – {wy}的一个网站。但是，有一些例外情况 – 在某些情况下，只有分版本的网站才行得通，一会你会看到这一点。
移动领域的竞争环境并不平衡
在桌面领域，对于我们前端开发者来说，形式正在好转 – 大多数现代浏览器已经对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）。
{zh1}，你拥有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的理念 – 但是刚才我也说过，有些情况下这是很难实现的，或者也是没有必要的。下面是这三种方法：
务必坚持遵循Web标准
创建一个xx独立的移动网站
只创建一个站点(One Web)，但是根据浏览它的设备和浏览器情况，添加优化代码。
现在，让我们开始对这些点逐个讲解。
坚持遵循Web标准和{zj0}实践
一个好网站的基础，是要有一个好的HTML结构，以及美妙的CSS（表现）和JavaScript（行为）。如果你认真地遵循Web标准，大多数移动浏览器至少会很好地解析并至少会基本可用，这是非常有可能的。例如：
一个网站，有良好的HTML结构顺序并在HTML中没有装饰性图片，在移动浏览器的单列模式或移动模式中，会呈现得很有逻辑性。
如果你的表单元素中含有“label”元素，浏览器将把它渲染得更有表单区域的感觉。
如果你给CSS和JavaScript使用了优雅降级/渐进增强技术，浏览器如果不支持、简化、忽略某些属性，这时站点的可用性几率会大大增加。
如果你花费时间精力去研究的话，在提升移动用户体验方面，还有更多事情可以去做。如果你的目标受众包括大量使用非HTML浏览器（例如支持WAP或CHTML的某些日本浏览器）用户，那么你可能不得不检测设备并提供适当的内容。
提供一个xx独立的移动网站
如前所述，我认为如果可能的话应该尽量避免使用这种方式。你可以做设备检测并自动重定向来避免给用户使用带来麻烦，但是这意味着你不得不维护两套网站。最主要的方法是通过UA嗅探来识别浏览器，或在服务端进行设备功能检测，然后再给用户提供相应的站点。在dev.opera.com，有很多优秀的文章来讲述如何实现 – 查看{zh1}的资源部分。
但也有例外，对于xx独立的网站来讲 – 你不得不始终考虑用户体验情况。某些类型的浏览设备可能不兼容于特定的网站或者特定的功能。例如，有一个大学校园网，带有部门电话号码的搜索功能，但同时也包含了一大堆校园历史的网页。如果你想去与某人会面却找不到他们部门时，你大概会想在移动设备上使用搜索功能，但你在外出的时候也不太可能想坐下来阅读那么多的文字。
在这种情况下，你可以使用下面提到的一些技巧，来为移动设备提供网站中某个功能的一部分，或者干脆为移动设备创建一套xx独立的网站。你只需检测用户使用的设备类型并自动提供给他相应的站点，并把这个过程xx公开给用户，但是很多很多人并不愿意这个功能把他们xx限制住，所以如果你要这么做的话，就需要给用户提供一个指向完整站点的链接，用户可以自行选择是否用它来访问完整站点。
一句话警告 – 设备检测很容易被滥用。你可能经常看到一个网站的桌面版本非常牛B，而它的移动站点却非常的垃圾。因为开发者只是将移动站点放在一个非常低标准的位置上。事实上，目标受众的设备水平并不均衡，现在很多的移动浏览器都具有处理完整Web页面的能力了！你应该尽可能地让设备发挥他们{zg}的处理能力，并且要发挥移动设备的特别优势，比如基于位置的服务（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”>手持类的媒体类型允许你针对移动设备使用优化版的样式（例如精简的布局和排版等）。这是一个被支持得很好的机制，实现起来也很简单，但它确实有它的缺陷。就像之前所说，它经常被开发者滥用，来给网站提供一个蹩脚的{zd1}标准布局。事实上，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或其他浏览器也不支持。解决问题的方法之一，是使用媒体类型和媒体查询的组合。这种方法在我的这篇文章中做过解释。这是一种变通方案，但肯定不够理想。这点在将来应该会有所改善。
摘要总结
目前就是如此而已。我希望我的移动开发世界之旅会对各位有所帮助。我在这只是抛砖引玉，要想深入学习的话，可以查看下面这些资源。
