我的问题是为什么我们必须将所有内容丢弃到设备？这似乎浪费了服务器上的处理,浪费了带宽,因为浏览器处理的内容较慢,因为他们正在使用的设备可能永远不会向用户显示某些内容.我错过了什么吗？回到服务器并让它将内容发送到适合设备类型的客户端不是更好吗？我们不应该关注移动用户的数据计划,而不是发送不适合其设备类型的内容吗？我在响应式设计上看到的所有示例都有桌面和移动/平板电脑下载到客户端的内容,这似乎是一种浪费.
我正在开发一个基于设备类型具有不同用户体验的时间输入应用程序.桌面(全屏时)具有更详细的数据输入体验,而移动/平板电脑由于设备空间较小而具有不同的体验.我正在开发应用程序,所以当桌面浏览器调整为小于768px宽的东西时,jQuery会调用服务器来替换“较小”的移动/平板电脑版本的UI.这个合适吗？我当然不想下载2个版本的应用程序,并根据设备宽度隐藏其中一个版本.
我使用jQuery方法走在正确的轨道上吗？我是否遗漏了有关响应式设计并需要为设备定制内容的内容？任何想法,建议和指导表示赞赏.谢谢.
I’m developing the app so when the desktop browser is resized to something smaller that 768px wide that jQuery makes a call to the server to swap out the UI for the “smaller” mobile/tablet version. Is this appropriate?
这听起来不是一个很好的方法你接受orientationChange帐户吗？
I certainly do not want to download 2 versions of the app and hide one or the other depending on the device width.
如果您在大多数平板电脑上以纵向访问网站并更改为横向,则必须在下载< 768px用户界面后下载> 768px用户界面.
zb4中的移动第一种方法(带有媒体查询)允许您防止属于大型设备的内容被下载到小型设备中.基本上,您从移动样式开始,如果设备满足您在媒体查询上设置的条件(默认情况下,您可以拥有比zf4框架更多的断点),则下一个规则会跳入.
我曾经在几个“响应式”项目中工作过,甚至回到了前媒体时代,我使用javascript来测量windowsize
关于javascript和喜欢@ powjames3说zepto比jquery更轻/更快,如果你可以编写自己的javacript函数将比使用过度膨胀的库好得多.
现在我做mobileFirst响应式webapps和网站使用混合的用户代理嗅探(有时决定什么图像src或脚本/样式src提供),尽管用户代理测试决定我总是提供移动第一媒体查询,并有条件地加载内容.
“As Ethan Marcote (and John Allsopp before him), were right to point out, the inherent flexibility of the web is a feature, not a bug.”
以下是一些可能使您走上正轨的资源：
用户代理解析和检测：http://mobiledetect.net/
教程http://www.html5rocks.com/en/mobile/responsivedesign/包括：
>为什么我们需要创建移动优先,响应迅速的自适应体验
>如何为自适应网站构建HTML以优化性能并优先考虑灵活性
>如何编写首先定义共享样式的CSS,使用媒体查询为更大的屏幕构建样式,并使用相对单位
>如何编写不引人注目的Javascript以有条件地加载内容片段,利用触摸事件和地理定位
>我们可以做些什么来进一步增强我们的适应性体验
希望能帮助到你