RESS:响应式设计 + 服务端组件

原文:http://www.lukew.com/ff/entry.asp?1392

  关于跨多网络设备的Web开发,从未停止过争论。有些人希望客户端解决,而有的倾向于服务端。但我越来越感兴趣如何将他们合二为一。RESS (Responsive Web Design + Server Side Components)就是这样的一个提议。

  在响应式的具体实现上,URL在设备在不同的设备上和所显示的内容上,都是一致化的。这就意味着,同一个链接要承载太多设备的体验。为了更好地自适应,网站通常需要一个单独的源顺序、单独的URL结构和灵活的可跨多屏幕尺寸的media query(也是因为这一点会成为性能瓶颈)。

  另一方面,服务端的解决方案是,他只会提供给客户端需要的内容。所以源顺序、URL结构、媒体资源和app的设计可以在发送到这一大批设备的浏览器里之前,都能经过很好的优化。但服务端的解决方案通常要依赖于浏览器重定向到特定设备的代码模板。每一类要保证适配备都需要自己有一套模板,这些模板基本都包含重复的代码,因为要适配各种设备。

  所以,客户端和服务端的适配都有好处和局限性。我们怎样取其精华去其糟粕呢?RESS(Responsive Web Design + Server Side Components)是我一直在探索的概念,可能会有所帮助。

  简而言之,RESS将自适应布局和服务端组件(并非整个页面)统一起来从而进行优化,所以一套页面模板定义了适用于所有设备的站点,但是一些具有特定设备样式的关键组件,是由服务端来渲染的。

如何工作?

  假设,移动和PC需要不同的导航方案,因为移动屏幕小,我们需要一个最小的头部,并且不能远离内容。但我们需要让用户用舒适的交互方式来使用导航,所以我们把导航放在页面底部,这样单手使用更加方便。
 
  但是在PC,我们希望在页面顶部的导航都是一致的。因为有足够的空间,完全可以把菜单内容展开给用户。下面你可以看到两种导航的不同之处:
要用RESS实现,我们得在页面模板里为页头和页尾使用两个变量(这里用Mustache来定义)。
<body>
{{>header}}
 
[...document content...]
 
{{>footer}}
</body>
 
整个页面使用弹性网格(flexible grid)和media query来管理多个分辨率的区间(breakpoint)从而发挥响应式设计的优势。但每个变量是一个组件,实现在服务端对特定设备类型的优化。在这种情况下:
 
header.html
mobile_header.html
footer.html
mobile_footer.html
 
如果服务端检测到移动浏览器访问,就呈现移动端组件,否则就退回"标准"组件。每个组件集合都是为移动严格优化的,发挥服务端方案的优势。
 
我们得到了在单独URL下的自适应布局,它集成了源顺序HTML、媒体、app设计、甚至是URL结构。
 
看一个简单的例子,我们可以在模板里通过一个类似 {{>userimage}} 的变量来为特定的媒体资源应用服务端组件,同时可以增加一些新的服务端组件,让不同的尺寸格式发送给对应的设备类别。
 
userimage.html 包含代码:
<img class="biguserimage" height="300" width="300" alt="{{username}}" src="{{biguserimage}}">
 
mobile_userimage.html 包含代码:
<img class="userimage" width="50" height="50" alt="{{username}}" src="{{userimage}}">
包含了这个组件的任何页面整体布局都被弹性网格(flexible grid)覆盖,并且我们发送给任何设备的media query已经被服务端所优化。这是与客户端解决方案最关键的不同点,虽然也都是达到类似的效果。
 
在实例中,我们想要完全优化/更改整个页面的内容,我们可以创建一个指定了全部内容的组件:
 
<body>
{{>imageedit}}
</body>
 
虽然这个方法可能很少在RESS中使用(如果不是的话,你最好完全拆开成单独的模板),它移除了URL重定向并且在服务端只替换了页面的整个内容。
 
有效么?
RESS能用在你的站上么?当建设我之前的东西,我们用了特定设备的组件实现我们的Blog。任何开发者只需要引用一个ID的变量(指向一个特定资源),我们的服务端组件就会为特定的设备做优化。这样,我们的开发者只需要写一套基本的HTML标记即可,不需要担心不同的设备。
 
当我们公司被Twitter收购时,我们刚要开始应用这套方案,应该是非常有前途的。那从此我开始考虑更广泛地应用RESS方案。
 
可能还会有未知的挑战。
 
依赖服务端的UA检测来决定引用哪类特定设备组件,在某些情况下可能会有问题。对于如何让UA检测更精确,还有很多争论。
 
深入地思考,哪些组件需要做成变量?他们在media query定义的区间布局中该如何工作?你可能有不止一个区间来处理给定的模板。大多数情况下,你只想要移动组件和一组标准的平板和PC,用自适应布局覆盖这些不同类型的设备。其他情况下,你可能想要墙壁那么大(TV)的组件。
 
可能我没考虑过其他情况和挑战,所以如果你有任何想法可优化这个技术,请告诉我。
 

转载于:https://www.cnblogs.com/xiaozy/archive/2013/05/02/3055292.html

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值