我现有的文章网站具有复杂的 UI，例如评论系统和投票系统。如果我创建 Google AMP 页面，是否还需要包含所有复杂的 UI（投票、评论系统）？如果我不将其包含在 Google AMP 中，访问者是否只能查看文章但无法与我的网站具有的功能进行交互？在现有页面之上重新创建另一个 amp 版本的页面不是需要太多工作吗？
【问题讨论】：
标签： amp-html
这取决于您的网站有多复杂，但您可能想要做的是遵循 GitHub 的示例并将一些高级功能隐藏在桌面网站上。我认为 AMP 页面应该被剥离为仅文章内容，至少在 AMP 项目为表单提供自定义元素之前。页面顶部或底部应该有一个清晰的“使用桌面网站”链接/按钮，以便那些希望与网站充分互动的人可以这样做。
这使得核心内容能够以优化的形式和最佳速度提供给移动用户，并且移动用户经常在移动中，因此他们可能不介意必须等到他们在桌面上发表评论或投票在某事上。然后，那些使用移动设备但仍希望在其移动设备上发表评论或投票的用户仍然可以通过切换到桌面网站来实现。
我这么说是因为我认为 GitHub 与代码编辑、问题/公关讨论等有很多潜在的交互，考虑到没有多少人会使用这些，加载到移动设备上可能有点过头了移动设备上的东西。他们将阅读帖子和代码，但不一定在那一刻进行交互。
我之所以这么说，是因为我一直在开发一个留言板/论坛，只使用 AMP-HTML（以及后端的 Perl）来测试使用 iframe 的表单实际可行的方法是使用 @ 987654321@。
好消息是它可以做到，它确实有效。我已经能够使用 iframe 发布新线程和回复等。坏消息是实施...
我想出的计划是通过 iFrame 加载 form 和 input 元素，通过 iFrame 的 src URL 中的查询字符串传递帖子编号和作者 ID 等基本参数，这将使用以编程方式创建一种模板语言。这已经很丑了。
然后，我在 iFrame 中使用 JavaScript 从查询字符串中获取参数并将它们添加到 input 元素（type="hidden"，以及 name 属性和 action URL表格正在发布中）。
然后我在form 上设置target="_top"，以便在提交时重新加载整个页面。为了使所有这些功能发挥作用，您的 AMP-IFRAME 元素需要以下属性：allow-scriptsallow-formsallow-top-navigation。
我想到了使用 AJAX，但由于某种我真的懒得解决的 CORS 问题，它在这条路上变得更加混乱。我也想到我可能做错了，可能有一些超级简单的方法。
这种技术允许我创建可用的表单，同时仍然通过 AMP 验证。问题是：真的值得吗？您显然可以使用您想要的任何服务器端技术，但它可能与您当前的桌面网站的实施有很大不同，并且在安全性方面可能需要相当长的时间来开发、测试和强化。
我个人认为不值得多花时间。我相信，当 AMP 项目开发出足够的方法来限制其使用时，他们最终将包含一个 amp-form 自定义元素。
【讨论】：