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