打开新窗口问题和右键click问题（散分）

[hax]

本文是我在csdn上讨论屏蔽右键问题（见http://www.csdn.net/expert/
topic/596/596689.xml?temp=.2618524）时，为说明国外在讨论问题的
境界领先于国内之论点时所翻译的文章。

译文摘自：http://bugzilla.mozilla.org/show_bug.cgi?id=71705

问题背景介绍：右键通常被用来激发context menu——上下文菜单，
根据不同的情况提供诸如在新窗口里打开、察看源代码（这是许多钻
牛角尖的人想屏蔽它的原因）、复制url、另存为、加入收藏夹等功
能。有些工具软件还把自己集成到上下文菜单中，如Flashget。
Mozilla和IE都提供oncontextmenu事件来处理上下文菜单（不仅针对
鼠标右键，也适用于Shift-F10）。问题在于按右键是否应该触发
onclick事件？

IE的做法是不触发，因此你不能捕获右键click，但使用onmousedown
可以捕获右键按下的事件。Opera 6更进一步，即使onmousedown也无
法捕获右键事件。Mozilla则可以触发，因此就引起了一些开发者关
于这种触发是否是一个bug的讨论。

-------------------------------------------------------------
Additional Comment #16 From [e-mail] 2001-03-30 10:56

不久以前，在一个w3c的邮件列表中，我参与了关于如何处理这样一
个事实即：除了Frameset DTD之外，“target”已经被列为不建议的
属性（译注：许多传统的HTML 3.2的元素和属性在HTML 4.0以及XHTML
1.0中被列为不建议的，并在XHTML 1.1中被彻底摒弃，例如元素font、
属性align等；frameset相关的frameset、frame、target之类也是仅
仅被保留在Frameset DTD中，而没有进入Strict DTD；被摒弃的特性
包括Frame的功能将以CSS Level 1和CSS Level 2来取代）的讨论。

许多人在需要页面上的连接在一个新窗口打开时都这样写：

<a href="somepage.html" target="_blank">

反对使用target属性指向frame之外的任何其它地方的论据在于：它强
制连接打开一个新窗口而没有给用户任何救援。它也没有提供任何标
签里内容的信息。最终一致同意的解决方案是这样写：

<a href="somepage.html" onclick="newWin(this.href); return false;">

newWin() 包含了window.open的句法。

这样做的论据在于新窗口应该是通过脚本打开而非作为HTML说明的一
部分，并且用户可以通过简单的关闭javascript功能来禁止打开新窗
口。它也比另一种可选的脚本更好：

<a href="javascript:newWin(somepage.html);">

因为这个连接是死的，除非用户打开了javascript功能；而在onclic
k的例子里，连接在javascipt被关闭时仍是可访问的。

现在来看上述讨论如何与这个bug（译注：指按右键触发onclick事件）
发生关联……

当我使用上面的脚本，我的意图是当连接被左键点击时打开一个新窗
口（正如你打开一个普通连接）。然而，如果我不想进入这个连接，
而只是想复制这个连接或者将其标上书签（译注：在IE里则是把连接
添加到收藏夹），由于onclick被右键点击触发，就变成了不可能。

我在以下页面http://www.visi.com/~hoju/humor.html里广泛的使用
了上面的脚本。

你可以说我不应该在首页这样使用，但谁又能判断我的意图（或者相
反）？请接受我这样做的事实吧……并且，btw，你也可以注意到这个
页面是遵从HTML 4.01 Strict 和 CSS的。

我可以理解这样的论点：onclick处理程序应该捕获任何click，然后
我们应该通过javascipt检测是哪个button……并且我也很乐意把它作
为一个workaround（译注：我不知道workarount的确切译法，但我感
觉这个词指一个bug的基于实践的替代性解决方案而非根本的解决方案
），但是你仍旧面对这样一个难题——用户和开发者的期望：onclick
（含蓄的）意味着左键点击。

如果你试图通过整个quirks-vs-standards模式来解决，那并不真正触
及到问题，因为较之javascript它更多的处理layout（请让我知道我
的假设在这里是否正确）。

我真的开始明白Blake（译注：另一个参与讨论的人，他的观点是DOM
2既然定义了button的不同值，就说明右键触发onclick不是bug）所说
的DOM2比我所写的更多支持这样的观点（译注：这句话比较难理解，
因为我的英语比较差。有兴趣的人可以看原文。我理解他的意思可能
是指DOM2不仅把检测按键值作为workaround，而可能暗示应该这样处
理），……但是同时，我知道它会违犯大量它之外的现有脚本（译注
：我理解这里指按DOM2之前规范所写的脚本）。
在此期间，我会更新我的脚本来检测哪个鼠标按键被按下以排除右键。
-------------------------------------------------------------

欢迎大家就国外开发者讨论的“境界”以及该问题本身发表高见。

欢迎转载，但请尽量保持本文完整（译错的地方还请指正）。

[hax]

右键问题的进一步阐述

参考文章同上。

根据Taras Tielkes的回忆，DOM 2 建议（而不是暗示）所有的按键都
是accesalbe的，也就是右键click应该触发onclick。他给出的建议是：
保持onclick仅仅服务于鼠标左键，使onmousedown和onmouseup适用于
所有按键，这样如果需要，仍旧可以实现对右键click的处理，同时建
议DOM标准也做出修正。

然而Dylan Schiemann提出了有利的反驳意见。他指出，考虑到Mac只有
一个按键，而linux支持3个按键，则DOM规范的做法就是nice、clean、
generic和cross-platform的解决方案。在onclick事件的event.button
为2时使用event.preventDefault() 理论上取消了contextmenu。他同时
认为理想的做法是让用户有权利保留上下文菜单，但也应给作者权利让
他们知道用户的选择：接受作者的上下文菜单，仅接受mozilla的上下文
菜单，或者将两者结合，尤其是第三种情况，应该有方法让作者了解。
我认为他的观点的启发性在于，我们需要给用户选择来避免脚本的滥用
诸如弹出许多窗口、关闭上下文菜单、强行保持焦点等，但同时也应给
作者权利了解他们的网页正在被如何浏览，用户许可那些选项。

我的一个想法是固然这许多设想需要靠浏览器和标准本身的发展来解决，
但这个思路值得借鉴，比如在我们用自己的contextmenu替换浏览器的
时候，是否应该在menu的最后增加一个“浏览器菜单”的选项，使用户
在必要时候也能使用所需功能呢？

继续上面的问题

主要还是两种意见的对立，一种认为远程在任何情况下都不能对右键
的使用做出响应或干扰。另一种意见认为由于类似应用程序的web开
发需要，应该赋予开发者对右键的控制。

有开发者指出0.9.2的不一致情况：连接的onclick事件响应所有的按
键，而button仅仅响应左键。

讨论同时还提到Accesskey的问题，以及类似的中键和Ctrl-左键的问
题。

对DOM规范，有一种新的意见认为，DOM只是要求必须有方法获得哪个
按键，并不意味着必须把没种按键事件都发送给脚本处理。否则必然
导致“兼容性”问题，行为既不符合开发者的期望也不符合用户的期
望。

最终问题的解决

如果你有耐心和兴趣看到这里，那么相信也不必让我辛苦的继续翻译了。

--- Additional Comment #50 From [e-mail] 2001-09-26 13:11 ---

Attaching patch. This patch disables right and middle mouse
clicks on all content objects (with the exception of text
fields due to a compatibility bug with existing code). It
does not disable right and middle mouse clicks on documents,
windows, and in the browser chrome. These events are already
widely used within the browser to provide internal
functionality. In addition, the firing of middle and right
clicks is correct per the DOM 2 Event spec and required for
the coding of complex applications. No equivalent event
exists. It is hoped that the current patch will fix all the
bug cases in question. It has been tested and does fix the
simple and common cases attached to this bug.


我想你已经猜到了，这是一个同时符合兼容性和符合DOM标准的方案，
令人惊讶的是，这个方案同时也很符合逻辑，又不失简洁（至少比在
IE里用onmousedown和onmouseup重构onclick要方便许多）。

看来至少我没有白看那么多鸟语。

[shoyour]

用JS保不住原代码的~！

[孟子E章]

哦？

[太古盟约]

啊！

[flylyke]

我在一个网站曾看到连IE菜单上的查看源文件都被屏蔽掉了的,而且死活看不到他的源代码

[Lostinet]

IE中不是用return false来做的。是event.returnValue
我觉得IE的方法最好。其他的都无聊。

[zlgun]

不要动不动就把右键点击和屏蔽原码划上等号
有时出于页面美观和功能的需要为用户提供上下文菜单是必要的
发贴人只是希望大家就国外开发者的讨论发表一下自己的观点。

[weidegong]

关注

[hax]

只有自由人了解我的用意。
哎，csdn的气氛真是不行。看来javascript版是再找不到与我心有戚戚者了。