读者 Glynn 写道
我想知道您是否曾经见过响应式网页设计，其中包含一个“查看完整网站”链接。 我知道在开发响应式设计时，我们应该避免完全隐藏内容，但是一些用户可能实际上更喜欢捏合缩放和在他们的设备上使用传统的水平菜单。
您见过这种设计示例吗？ 您认为如何实现它？
我认为这是一个非常有趣的问题。
曾经有一段时间，我们嘲笑任何没有提供“完整网站”链接的移动版本网站。 但是随着响应式设计开始流行，我们看到这种情况越来越少。 事实上，我不确定我是否在使用响应式设计专门适应移动屏幕尺寸的网站上见过这种设计。
为什么我们看不到选择退出响应式设计？ 我认为有两个原因
- 在技术上实现起来比较困难，而且没有太多先例。
- 这表明您在响应式设计方面做得不好。
后者可能是更重要的因素。 就像：如果我们不确定它是否是一种更好的体验，为什么要创建这种响应式设计呢？
一种可能合理的场景是不同用户有不同的用例。 也许大多数用户访问该网站是为了阅读，而您的响应式设计很好地适应了阅读。 但是有些用户是为了完成其他任务，对于他们来说，响应式设计反而是一种阻碍。
实现它
我还没有真正做过，但理论上我会这样做。 如果你选择了桌面优先而不是移动优先的方法，这会更容易（我认为）。
1. 查询参数切换
也许
http://yoursite.com/?resp=no2. 删除视口元数据并对主体进行分类
然后您测试该参数。 我将在这里使用 PHP，因为它可以是任何东西。 我们只会在他们不想使用响应式设计时删除视口元标记，并向主体添加一个类。
<head>
<title>My cool site huzzah</title>
<?php
if (!$_GET['resp'] == 'no') { ?>
<meta name="viewport" content="width=device-width">
<?php } ?>
</head>
<body class="<?php if (!$_GET['resp'] == 'no') { echo "resp"; } ?>">您可能希望在这里更复杂一点。 您将需要设置一个 cookie（或使用 localStorage）来记住用户的偏好。 然后您不要只测试查询参数，还要测试该 cookie 的值，然后再决定是否排除视口元数据（以及主体类）。
3. 限定您的媒体查询样式
一种方法是排除加载包含所有响应式样式的单独样式表。 这可能适合您，但我通常喜欢将尽可能多的 CSS 保留在一个文件中。 如果您确实将其保存在一个文件中，您可以使用“resp”主体类来确保媒体查询样式不会在不应该的地方生效。
.page-wrap { width: 80%; }
@media (max-width: 600px) {
.resp .page-wrap { width: 100%; }
}这样，响应式样式只有在媒体查询匹配且主体上有适当的类，表明可以使用响应式样式时才会生效。
4. 拥有良好的 UI 来在两者之间切换
无论您想出什么方法，都要确保它能够清楚地表明如何在这两种网站样式之间切换，并且能够正确设置 cookie。
我还没有在实际使用中见过，但我考虑过在使用 RWD 的网站上进行改造，其原则是，现有用户可能会感到困惑，因为桌面设计没有改变，因此最好至少让他们可以选择从移动设备上查看“桌面”版本。
我编写了一个关于如何实现它的演示：http://neilcarpenter.com/2012/05/creating-a-faux-view-full-site-button-for-responsive-sites/
然后我在其他地方找到了一个更好的解决方案，它在视口元标记中设置了一个固定宽度：http://creativeandcode.com/responsive-view-full-site/
此外，与这类似，Boris Smus 的 Device.js (http://github.com/borismus/device.js) 允许动态切换不同的视图 – 首先是基于视口宽度，也可以由用户手动选择。 演示在此处：http://borismus.github.com/device.js/sample/desktop.html
之前想出了一个解决方案（也发布在 CSS-Tricks 论坛上！）。 使用 JS 修改视口标记，不需要类限定，从而导致（可能）CSS 过于臃肿。 还使用 localStorage 来保存用户的偏好。
http://creativeandcode.com/responsive-view-full-site/
是的，我也有同样的想法。 我甚至为此创建了一个小型库，并将其扩展了一些功能。
http://responsiveviewport.com
“ReView 是一个动态视口系统，提供高效的响应式网页设计视图选择”。
事实证明，当您希望能够双向切换，尤其是在页面缩放时，会变得很困难，但仍然可行。
如果有人想帮助我推进我目前的工作，我可能很快会将其开源。
很高兴您包含了关于保存用户偏好的部分。 当您在移动设备上点击“查看完整网站”，它将带您进入完整网站，但只要您点击其中的任何内容，它就会带您返回到移动/响应式版本，而不是停留在完整网站上，这真是太烦人了。
我前几天刚想过这件事。 实现它并跟踪分析信息以查看人们是否实际使用它会很有趣。
我绝对同意您的观点，如果有人要求这样做，那么响应式网站肯定存在一些缺陷。
我其实也想过这个问题。
也许设置一个 cookie 会是一个更简单的选择，并且不需要服务器端代码。
有点相关。
我在 Android 上的 Chrome 中加载了 css-tricks 并点击“请求桌面网站”，看看是否能实现这篇文章的目标。 它没有生效。
但奇怪的是，它让您的标题字体看起来像用奇怪的粗体和普通字母混合的勒索信。 是怎么回事？
我认为要记住的重要一点是，您只能知道大多数人的想法。 有些人很固执，他们不想使用您花哨的响应式设计。
假设每个人都喜欢您的设计是愚蠢的，也是不负责任的。 人们会在网站上接受它，因为这就是您的网站的样子，但如果您为移动设备进行更改，他们现在就会有东西可以与之直接比较。 有些人会想要旧的方式。
“相信我，这对您有好处”是一种非常粗鲁的思维方式。 首先满足大多数人的需求，但也要确保您不会疏远少数人。 当人们知道您拥有他们想要的东西，但拒绝给他们时，他们会感到非常疏远。
我认为这种思维方式很重要。 用户优先。 不要愚蠢地使用响应式设计，不要因为它“应该”而快速地实施它。 所有这些都取决于上下文 – 网站类型、访问者类型等等 – 基于逐案研究和分析。 我自己也遇到了这个问题，我希望能够在完整网站上进行捏合缩放 – 但这主要是在布局响应式做得不好，并且“次要”内容被随意隐藏的网站上。
另一个*大*障碍是 JS。简单的 RWD 只要 CSS 就可以搞定，但对于复杂的、繁重的任务，JS 是不可避免的。这不仅仅是简单地交换样式表的问题。你可能需要为“在移动设备上缩放的桌面视图”用例移植或重写客户端功能。这并不漂亮也不诱人。
我前几天就在想这个问题，你提到了一个我之前没有想到的解决方案。但我能看到在 URL 中添加字符串的问题是，如果你复制链接并分享到某个地方，你就会分享非响应式版本的网站，这可能不是你想要的。
我希望我能告诉你一些更有用的想法，但我没有。除了 cookie，我真的不知道还能做什么？
基本上，我的结论是，如果你担心是否需要一个“完整网站”链接，你可能还没有准备好提供响应式网站。在我自己的案例中，我被要求为一个长期存在的 CMS 和他们所有的客户创建一个响应式样式表。出于显而易见的原因，这极其复杂，我无法提供一个适合所有解决方案的单一样式表（主要是因为他们的代码是非语义的），因此由于时间限制，我们被迫采用重定向到移动网站的方式。
链接应该指向自身，由 JS 设置 cookie，这样 URL 就永远不会改变…
P.S. 显然，body 上的类名将取决于 cookie…
只是一个想法
你可以只使用 example.com/?resp，然后你的 if 条件看起来像这样：`if (array_key_exists($_GET[‘resp’]))`。
我阅读本文时的想法是用一些简单的 JS 来实现：http://codepen.io/WouterJ/pen/HBukj
通常，我喜欢将响应式设计限制在一定的宽度，超过该宽度后就固定，因为我不喜欢文本区域的宽度过大而高度过小，长段落经常只占据两三行。我认为这会影响可读性。如果要在某个点固定宽度，最好使用两个 CSS 文件：一个用于基本宽度或最大宽度，另一个用于响应式设计。这样，如果 URL 或存储的 cookie 指示不要响应式，你甚至不必加载第二个 CSS 文件，这可以节省相当多的带宽。
对于那些需要响应式设计的人来说，这会增加一个额外的 HTTP 请求，但尤其是对于比较复杂的网站，对于那些不需要响应式设计的人来说，节省的总数据传输量可以相当可观。
有一些很好的理由这样做
– 正如其他人所说，用户会因为桌面视图和移动视图之间的变化而感到困惑
– 不支持旧手机的响应式设计（我的设备无法看到图标字体，因此我看到 A、M 作为导航……而桌面版本则在图标旁边显示完整的单词）
– 我们处理图像的方式（max-width: 100%）可能是个问题。如果你放大查看细节（比如图表）……你做不到。当然你会想“长按并在另一个窗口中查看”，是的，我确实这样做，但我最近看到一条推文，有人说“RWD 很烂……我无法放大图像”。
我们是否需要在所有图像上提供一个带有 target: _blank 的链接，以及一个图标或文本来说明可以查看完整图像？也许……
– 带有代码示例的页面。我第一次用我的（旧）手机打开了*这个*页面……我无法看到代码，行被截断了（小屏幕缺少 word-wrap: break-word 吗？）。这种情况经常发生（可能是设备相关的？）
随着智能手机和 RWD 网站越来越多，我认为“困惑”的问题正在减少。
不支持 font-face 不会成为一个长期问题
我们可以考虑图像，并告诉用户他们可以全屏查看……
我认为代码问题不是问题，当我们需要查看代码时，我们可以用更大的屏幕来查看；）
我们在 ux.stackexchange 上就“用户是否应该被强迫使用响应式设计（无法选择退出）？”进行了广泛的讨论。结论是“不，应该提供选择退出”，但没有提供如何在现实中实施的例子。这是一个不错的解决方案。
http://ux.stackexchange.com/questions/20824/should-users-be-forced-into-a-responsive-design-without-the-ability-to-opt-out
你网站之前的版本更好。
我希望你能改回原来的版本。
你应该写一篇博文，认真地专业地分析为什么旧网站更好，这对我们双方都有帮助。
我要将这个话题埋掉，因为它与本文无关。
我现在正在开发的一个 web 应用中（移动优先设计）就是这样做的。页面有两个样式表
Stylesheet1 包含所有移动和通用样式。
Stylesheet2 包含所有桌面特定样式，并在 <link> 标签中使用媒体查询进行限定。<link> 标签也带有一个 id。
如果用户希望在适用移动设备的场景下强制使用完整网站设计，或者反之，我们提供一个按钮，用户可以点击“切换到移动|桌面”。点击该按钮会使用 javascript 更改 Stylesheet 2 上的媒体查询。
如果强制使用桌面，媒体查询将更改为“all”。如果强制使用移动设备，媒体查询将更改为“none”。
然后，首选项将保存在本地存储中，每次后续页面加载时，如果设置了首选项，就会应用它。
结果令人惊叹。布局之间的切换是即时的。没有页面重新加载，也不需要等待另一个样式表下载。对我们来说完美有效。
当然，这需要 javascript，但我们的应用程序本身就需要 javascript。
好主意，希望你能为此做一个演示。:) 谢谢！
移动网站上的“查看完整网站”链接是公司提供“移动精简版”体验的遗留产物。如果用户想要执行任何复杂的操作，他们必须离开移动网站并访问桌面网站。这是一种“移动精简版”的逃生路线，而且效果不错。
我认为，随着设计师现在在响应式网页设计中追求内容（和功能）的平等，这个功能（虽然在某些情况下有用）不再是首要任务。
嗨 Pon，
你的观点非常有效，但不能适用于所有用例。例如，我们的网站销售童装，因此我们的大部分客户是 30-40 岁的母亲。她们可能拥有最新的移动设备，但可能不经常浏览移动网站或使用 Facebook 等应用程序，而这些应用程序可以帮助她们熟悉移动设备特定的导航模式。某些用户在这种用例中只是更喜欢使用熟悉的菜单进行导航，因此应该提供给她们这个选择。这并不意味着设计有缺陷，仅仅意味着我们作为一家公司不会忽视那些技术水平较低的客户的偏好。
嗨 Glynn，
我同意你的观点，网站和受众的具体情况应该决定设计决策。
我建议不要使用查询字符串，因为当用户分享链接时，下一个用户将无法选择响应式设计。
这与我对移动网站的抱怨是一样的。你访问完整网站，然后被烦人地重定向到移动网站——当你分享指向该页面的链接时，每个人都会看到移动网站，即使他们在使用桌面电脑，因为你的链接指向 mobile.blah…
除此之外，我认为这确实是一个有趣的问题。也许这应该由用户代理来实现？
好问题。
我个人的观点是，提供一个没有针对当前屏幕进行优化的布局，这就像认输了……尤其是如果你已经花费时间进行了优化！
有时我发现情况恰恰相反，移动网站比超宽屏幕版本的导航和操作更容易。你只对屏幕上的一个小区域感兴趣，但现在充满了广告或侧边栏文章等。
你是否会提供一个“查看简单布局”选项？
我肯定会希望某些网站提供这个选项。要么提供这个选项，要么即使我需要，他们也允许我使用响应式设计访问所有内容。有些网站过于限制了！
我完全同意这两个原因，尤其是第二个。我也认为大多数用户不会知道选择退出“响应式”版本意味着什么。这是一个关于命名的挑剔问题，但我的父母可能会认为这意味他们将请求一个加载缓慢的页面。
实际上，几周前我就有类似的想法。我认为在显示移动网站之前，我们应该有一个“过渡区域”，在这个区域里，你可以提供一个快速加载的页面，上面有两个按钮和一个问题：“你想要哪个版本的网站？”移动版或完整版。
我经常听到人们抱怨他们的手机上的移动网站糟糕，或者因为人们只是将变量传递到网站而没有做任何事情来保持它“设置”（会话、Cookie 等），所以他们会陷入无限的重定向循环中。因此，用户点击（或轻触）后，变量就消失了，然后 BOOM，他们又回到了移动网站。
让我们做得更好，伙计们！
我不知道这是否一定是最好的解决方案。它让人想起初始页面。
另外，你如何传达两种网站类型之间内容的差异？我访问网站时可能要查找的内容可能在“移动版”中可用，也可能不可用。
“有些人固执己见，不想碰你的花哨自适应设计。”
几个月前，我在自己运营的一个大型体育新闻网站上遇到了这个问题，当时我引入了自适应设计网站（不是严格的响应式设计，因为它使用的是RESS技术）。
一些用户抱怨他们不喜欢被迫查看“小屏幕”布局，想要选择退出并捏合/缩放/滚动“桌面”版本，所以我实现了一个Cookie解决方案来存储他们的偏好。看起来效果不错。
我非常想听听使用过这些技术版本的人的指标。
我感觉“响应式设计”很快就会取代“基于表格的布局”，成为你所有喜欢的“记忆中的”网页设计名言。当人们找到我们以前的设计，其中所有内容都挤压成一个瘦长的、无尽的滚动条的巨人豆茎时，我们都会脸红。
我们一直在听到关于“响应式设计”激动人心的演变。但对我来说，它比不上移动浏览器的激动人心的演变。（顺便说一下，移动浏览器已经非常擅长渲染旧的桌面时代网站。而且很快，它们很可能会为我们提供管理资产加载相对于带宽的原生功能。）
有人可以谈谈他们的退出指标吗？
我尝试为地球之友EWNI网站做了一些响应式设计工作，http://www.foe.co.uk。它远远没有 Chris 做得那么出色，但我确实决定在底部添加“切换到完整网站”链接。我决定添加它的主要原因是，我使用的移动设计隐藏了很多东西，如果用户正在寻找更多内容，我不想让他们感到沮丧。我不确定实现是否很好，但它起作用了。
– 我有一个常规的非响应式样式表和几个响应式 CSS 文件。
– 点击底部的“切换到...”链接会设置和取消设置 Cookie。
– 然后在 JS 中，我测试您是否使用的是 IE <9，是否已关闭 JS 或是否已设置 Cookie，如果是，则只使用非响应式 CSS。否则，则设置响应式 CSS 文件。
我很想回头改进它（比如正确优化它，它急需优化！），但我们没有时间...
无论如何，看到这篇文章真的很惊讶，因为我以为我是唯一一个会想到在响应式（ish）网站上添加“切换到完整网站”链接的人！
我担心我没有关于点击它的人数的统计数据，但我认为我会尝试在它上面添加一些事件跟踪，同意其他发帖者的观点，了解这些数据会很棒。
抱歉，我只是想纠正一下，我不使用 JS 来检测 IE <9 或 JS 是否已关闭，那样太疯狂了！我只使用 JS 测试 Cookie，另外两个使用条件 IE 标记和标记完成...现在该睡觉了！
我很想看到一篇关于这个主题的分析，类似于你关于响应式表格的总结；看看提供到移动版或完整版网站链接的各种方法。
例如，通常，在我的 iPad 上，我会看到一个网站的 iPad 版本，但我不需要也不想要它。我想看到我在笔记本电脑上看到的同一个网站。对于 iPad，我认为不需要专门的版本，因为它很容易查看页面。当然，也有例外，但总的来说，在平板电脑上，我更愿意看到完整版网站，或者至少有这种选择。
很棒的文章和评论。它正好赶上我正在为我正在构建的当前网站迁移到响应式设计的决定而苦苦挣扎。我一直希望有一个你描述的按钮。
我 iPhone 上 Safari 中地址栏上的“阅读”按钮完美地做到了这一点（我的网站不是响应式的）。它从我的首页中提取了我会选择的精确内容，并以易于阅读的字体大小在一个阅读窗格中显示，该窗格叠加在我的网站上。也许将来，网页浏览器将在优化移动网站方面发挥更大的作用。
这可能是一个巨大的挑战。然而，我认为没有必要这样做：如果你的用户想要关闭响应式版本，那么为什么要做响应式版本呢？
我的意思是，如果出现了这个问题，你的用户体验可能很糟糕。
对我来说，即使这个想法很有趣，它也会给网页项目带来不必要的复杂性。
有时我只是想看看“大”网站是什么样子的。响应式设计可能很棒，但提供选择有什么害处呢，尤其是如果它很容易做到的话。
嗯，如果你使用的是 WordPress，你可以简单地使用主题切换器插件，并且拥有完全相同的主题，只是其中一个是响应式的，另一个不是。
我一直对响应式设计持怀疑态度。我认为它是一个很棒的解决方案，而且它一定会存在下去。我一直对我们行业整体如何仅仅接受了它并决定“这是解决方案”感到有点保留。
我的犹豫部分源于此：响应式设计“假设”用户不介意大量上下滚动。这是一个非常糟糕的假设。许多人喜欢双击放大部分，或者使用手势放大等。
为用户提供选择绝对是需要考虑的事情。好文章。
我很想看看人们点击“以完整模式查看网站”按钮的指标，就我个人而言，我认为这是一个坏主意。如果你正确地构建了响应式网站，那么它肯定消除了回退到桌面网站的必要性。
我个人对此持 50/50 的态度，这是一个很棒的问题。我无法真正看到在小屏幕上查看完整网站有什么好处，但是也许这是用户的选择？看看结果会很有趣 :)
请记住，移动浏览器旨在使浏览“完整网站”尽可能优化。
当我们进行响应式设计（和开发）时，我们假设我们量身定制的方法对于每个尺寸范围都是理想的，但这对于每个用户而言并不总是如此。正如你所提到的，这与用户的选择有关。
###如何进行以下 3 步操作
> 在 body 中关闭所有平板电脑和移动媒体查询：body:not(.normal-view) {…}
> 点击切换按钮
删除视窗元标记 在 body 中添加 {.normal-view} 类
> 记住用户偏好
我认为它应该有效。
我在 5 月份自己也涵盖了这一点：http://russellbishop.co.uk/writes/code/responsive-web-design-opt-out/
但最好在这个解决方案中添加一个规范标签，否则你可能会遇到重复内容问题......
我喜欢让用户选择他们想要查看网站的方式的想法。但我只是在想：在移动优先 RWD 网站中这真的有意义吗？
不错的提示，只是一点评论
如果你使用
<?phpif(isset($_GET['resp'])){
// 代码
}
?>
会更好
评论永久链接#
评论永久链接#
我遇到过一个客户，他绝对讨厌网站看起来不一样，我认为他去过太多糟糕的响应式网站，完全搞砸了体验……但归根结底，他付钱，他的意见是“我只想确切地知道所有东西都在那里，我没有错过任何东西”。
我个人认为，在这种情况下提供一个退出链接是个好主意。当然，大多数浏览器都有一个请求桌面版本的选项……但在我看来，想要“完整的桌面版本”的用户可能也是那些不会在应用程序菜单中搜索的用户……我不知道，这只是一个猜测。
实现起来非常容易。
很棒。我刚想开始学习响应式网页设计和媒体查询，并了解一些非常重要的东西。感谢这篇文章。
此致,
TheIToons。
我认为这是一个好主意，并非所有移动网站都很好，在我看来，提供一个选项会是一件有益的事情。
我对这件事有复杂的感觉。虽然我同意好的RWD应该意味着UX针对关键的设备尺寸进行了优化，但我认为在某些情况下应该提供桌面版本。
除了评论中提到的合理理由外——尤其是图像缩放和用户感觉可能没有获得“完整”体验——用户可能在其浏览器选项中明确请求了“桌面网站”。除非我正在查看网站的“m.”前缀的移动版本，否则此设置在响应式网站上没有任何作用。或者更确切地说，它确实做了一些事情（更改了用户代理），但没有效果。
尽管我讨厌自己建议它，但这可能是用户代理嗅探的有效理由吗？如果用户代理不包含“mobile”，但视窗大小表明并非如此，我们可以假设用户正在请求桌面版本并相应地采取行动吗？