照顾小屏幕设备

原文位于:http://stopdesign.com/log/2004/12/16/small-screens.html

照顾小屏幕设备

16 十二月 2004

上个星期早些时候, 我在波士顿举行的Web Design World 中向观众们作了演讲。 Clearly the conference scene is heating back up, as budgets for events and off-site training seem to be reappearing. 我所演讲的两个话题 (“ 用CSS设计漂亮的用户界面” 和 “ 把表格扔出窗口”) 充满了趣味。在我的最后演讲结束后，我必须冲向机场来赶乘航班。所以我没有流下来听余下的演讲会或者跟更多的与会者在接下来的两天中进行更多交流。

然而, 我总结了几个演讲后提出的问题。这些问题提得都很好, 而且也反映了我们很多人每天都会遇到的问题。考虑到这个, 我想我应该把这些人们会后提及的问题进行分享, 还有就是我的即兴的回答 — 有些挺有水平的, 有些却组织的不怎么样。

我不一定总是能当场就能做出回答, 但我会在我可能的时候帮助寻找问题的答案。 还有我想真正了解了我的朋友们问什么会很有帮助。 不管是什么，这些问题触发了引人入胜讨论, 它们会吸引那些能够帮助提供答案或者能够把你我指向正确方向的人们。

 其中一个在波士顿要讨论的问题就是如何解决便携式设备 (像手提电话和PDA)。 尤其是, [用我自己的话表达] 有一位朋友对一些设备感到很沮丧, 比如Pocket PC , 它会忽略通过handheld媒体类型进行链接的样式表,却会应用任何指定为screen媒体类型的样式表。它把css的一部分搞乱了, 令一些专门为较大的桌面浏览器设计的样式乱套。 如果我们可以像在Netscape 4中那样有方法来在移动浏览器中隐藏screen媒体类型的样式表，他就不会抱怨了。 但是由于Pocket PC 对CSS 削弱的支持, 加上它还尝试把一个本用于桌面浏览器的设计强加到一个小窗口当中, 让他感到毫无办法。

我以前也曾经在 Danger 的 Hiptop 上听到过类似的抱怨。

首先, 我考虑了为什么先进大多数的移动设备浏览器不支持 handheld 媒体类型。 然后还想到一个临时应急的解决方法。( 我必须声明这些都只是我自己的观察和理论, 对于移动工业我完全是个门外汉。 )

Show of hands for handheld support?

那么为何到现在 handheld 媒体类型都没有被支持呢? 为什么移动浏览器的厂商一开始就按规范办事?

 我们已经看到在过去的一年,支持网页浏览功能(具有某些功能)的移动电话和 PDA 急速增长。它们已经做得越来越好。 制造这些浏览软件的厂商都希望使用产品的客户尝试浏览网页时尽可能的获得“最丰富”的体验。 假如移动浏览器还像1996年的时候那样不使用任何样式来显示页面 — 若大多数的网站都没有提供handheld样式表的结果 — 那么客户将会在他们台式机或手提电脑中的网站模样和电话或PDA中的模样之间产生一个生硬的落差感。 如果移动浏览器没有尽可能的显示内容，那么有一些用户熟识的标志和设计可能会消失。 这些浏览器都尝试为每个站点显示尽可能多的样式。这也经常会对那些知道应该要提供handhelp媒体类型的开发者造成问题。

这是一个先有鸡还是先有蛋的问题。 因为 - 现在 - 几乎没有网站为手持设备提供专门的样式,所以移动浏览器软件公司也并未对handheld媒体类型提供内置支持。然而, 设计者和开发人员只会等到至少有一些浏览器可以稳当的支持handheld样式表时,他们才会开始使用这一技术,并且会马上看到提供这些额外样式表的好处。

很明显, 移动浏览器的问题并不独特。它将会持续，而且只会变得更加流行。我们必须考虑到成千上万尝试浏览我们站点的移动设备。并且，我们需要把站点设计、建造成可以在任何地方工作。包括了残疾人士使用的设备,还有就是很多我们还没有看到投放市场的各式各样的浏览工具。

我们不希望回到 1997, 那时我们被迫为进入市场的不同浏览器建造不同版本的站点。诚然在一些情况下, 为了获得更好的移动设备体验必须优化一个站点, 这个可能意味着完全不同的架构, 把 HTML 结构单独出来。但如果我们有机会, 我们都希望根据显示设备的类型来优化内容的设计或呈现。

现状需要改变。它要求浏览器制造者以及创建前沿站点的设计人员和开发人员的行动。 那些站点为其它的站点设立了榜样。 两方都不应该去想是不是先走一步，他们只要去做就行了。

 在我继续之前, 我该提及至少有一家公司的浏览器能正确地支持handheld媒体类型。Opera的Small-Screen Rendering 技术在处理移动设备显示网页的挑战方面已经迈进了可观的一步。由于大部分页面还不使用handheld样式表, Opera 会使用 SSR 技术来最优化页面显示。然而, 当Opera检测到一个页面存在handheld媒体类型的样式表时, Opera 假设作者已经为小屏幕设备优化了页面, 它将正确的应用handheld样式表, 并同时禁止 SSR 来防止作者的意图被打乱。所以在 Opera 当中, 使用用handheld样式表的一面能够一如作者希望的那样被显示。但一个没有 handheld 样式表的页面就会应用 SSR 方式，一个明智的兼容方案。

直到那一天…

尽管Opera做了一个好榜样, 那么那些现在还不支持handheld媒体类型的其它浏览器怎么办呢? 我们基于相同的HTML， 如何设计和创作具有健壮样式表的站点, 令不管用何种设备访问站点时,网站都还能那么吸引并且可用性高呢?

我对这位朋友的回答, 包括了用 JavaScript 来检测小于X的屏幕大小以强迫支持 handheld 样式表。 一些人可能不喜欢用JavaScript检测浏览器类型或窗口宽度检测。 但当更多浏览器支持手持媒体类型时, 我们需要一些实用的兼容措施来有效的为小屏幕优化和设计。

我先是建议他加入一个后备的 handheld 媒体样式表。然后用 JavaScript 检测较小的屏幕尺寸。如果检测到, 把后备样式表的媒体类型改为 screen 和 handheld, 加到 (并且覆盖) 默认的screen 媒体类型样式表。备用的样式表 (为移动浏览器设计) 可能包含了去除用于页面布局的浮动对象和绝对定位规则, 和去除所有列和容器固定宽度的规则。理想情况下, handheld 样式表允许设计能变为单列、可变宽度以自动适应屏幕宽度。

我这个建议存在的问题? 很多这些新的移动浏览器还不能完整地支持Javascript，甚至一点都不能。其它一些可能因为安全原因或“用户的方便”而在默认情况下禁用了Javascript。呸,吹牛!

第二幕

那么反过来做会怎么样呢?

如果我们首先为屏幕和手持媒体类型应用一个很简单的样式表。 这个基本样式表仅包含指定颜色、字样、链接处理和简单列表样式的规则。它不包含复杂的漂浮列或者绝对定位。这个样式表能够照顾到所有支持CSS的设备，而不管它支不支持handheld媒体类型。

然后, 我们用 JavaScript 来检测宽屏幕 — 通常暗示着桌面浏览器。 如果浏览器支持Javascript, 并且检测到宽度足够(假定是 620px 或更大— 又甚至是 750 如果你的设计只能在 750或更高像素工作), 在这里我们不但假定了一个桌面浏览器可以使用, 而且对任意具有足够窗口大小的浏览器皆能一如所愿的显示多列排版的设计。这种情况下, 我们加入主样式表把页面区分成标准的多列布局。那些不支持Javascript(或被禁用)的浏览器或者没有报告足够屏幕宽度的浏览器只能得到基本的样式表。

看起来这样就能起作用了。当然，我只懂得足够的 JavaScript 来胡乱修改现有的代码, 但还不足以轻描淡写地就写出来我自己的一份。 所以我甚至不会尝试去写这些或者做一个示例什么的。 其它朋友请提出意见或者写些代码来看看这个想法是否可行。

我会说这其实根Cameron Adams的解决方法很相似, 他近来提出了一个相反的问题: 如何为更宽的浏览器窗口提供更多的内容。 (参阅他的Resolution dependent layout(不依赖于分辨率的布局方法) , 21 Sep 2004.) 在本例中, 我只是建议了在Cameron所做的基础上向后退一步。 我的想法是先为屏幕和手持媒体设备设定简单样式表来照顾一些支持CSS设备的最低要求。检测到了更宽的窗口宽度会应用更高级的样式表来把页面分解为多个列。 而 Cameron 的想法就是进一步为超宽屏幕的设备提供更多的样式。

防止 FOUC

假如上面说的是可行的话,我还要罗嗦一句。 我会建议如果检测到了宽屏幕,可以通过Javascript设置一个 cookie 。当设置了cookie后, 服务器端代码就能够在接下来的页面中检测到那个Cookie, 并在HTML传输到客户端前决定是否需要添加主样式表。通过这种方式, 我们防止了第一次浏览页面以后的页面中发生的FOUC 问题。

Feedback, expansions, modifications, pitfalls? Code samples, examples, or other ideas?

Posted at 5:00pm in CSS , Events , Technology