2

我知道有很多关于 ASP:Menu vs. WebKit 问题的帖子，但我找不到能回答我问题的帖子。

我经常看到人们推荐两种不同的方法来解决ASP:MenuApple WebKit 浏览器（即 Chrome、Safari）中 s 的问题。但实际上哪个更好？除了目标用户代理之外，这两个操作之间有什么区别？我发现的唯一区别是第二个也适用于该Page_Load事件。我认为一个客观上优于另一个，但我不知道它们之间的区别。他们每个人是如何工作的？

两者都Page_PreInit()采用基本页面的方法。

1.清除浏览器适配器。

if (Request.UserAgent.Contains("AppleWebKit"))
{
    Request.Browser.Adapters.Clear();
}

2.改变客户目标。

if (Request.UserAgent.Contains("Safari"))
{
    Page.ClientTarget = "uplevel";
}

Google Chrome 的默认用户代理如下。它同时包含 Safari 和 WebKit，因此我怀疑目标用户代理是否存在显着差异。

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.X.Y.Z Safari/525.13.
4

1 回答 1

7

好吧，我自己“解决”了这个问题，因为显然没有其他人知道。实际的答案是 ASP.NET 将使用 WebKit 的浏览器识别为“下层”浏览器，这意味着它们无法处理现代 HTML 或 JavaScript。作为补偿，ASP.NET 使用“适配器”以不同方式呈现菜单标记。

在情况2.（更改客户端目标）中，客户端被强制识别为"uplevel"浏览器。因此，菜单会正常呈现，就像 Internet Explorer 或 FireFox 一样。

在情况1.（清除浏览器适配器）中，客户端仍然被视为下层，并且插入了一个适配器以补偿所谓的旧浏览器，但在它可以使用之前，所有的适配器都被清除了。

因此，我得出结论，技术上方法2.更好，因为

  1. 它在使用适配器之前有效地停止了低级浏览器补偿。
  2. 如果该事实在应用程序的其他地方使用，它会正确地将浏览器识别为上层浏览器。
  3. 它没有清除适配器，用户可以合法地将其用于其他目的。
  4. 正如我在问题陈述中所说，它可以用于Page_Load方法而不是Page_PreInit方法，从而允许将其添加到母版页中，而无需继承的基页。
于 2011-04-07T20:07:51.700 回答