那就由你 Conet 放上去，然后标明源自那个页面，以及“如果你是原作者并感到这样侵犯了你的权益，请告知我将脚本撤除”。
由你去实现这些建议应该没问题吧？
……我不喜欢到 Opera 论坛跟那些人打交道……

不过要不要这样做还是你作决定吧。

hzhbest：Conet 是作者吧？我有几个建议：
1. 右上角浮动块的样式，“position”属性改为“fixed”，在代码中把计算浮动块位置的代码去掉；或者如果你觉得滚动时隐藏浮动块是必要的话（我觉得没必要），上述属性照改，代码换成切换“display”属性的代码。
2. 翻页分隔条的做法不好，随便在 Google 上搜个东西那 Url 都很够长，然后在那分隔条上卷起来都够一个搜索结果的高度了；我建议代之以“第2页”“第3页”（如 Autopagerize 那样）的文字链接；我觉得没有必要显示完整或部分 Url （毕竟翻页翻到哪都还是同一个网站同一系列网页）。
3. 放到 userscripts.org 上。记得添加这个脚本所参考的其他脚本的链接并向那些作者致谢。
4. 为了吸引更多用户，请不要使用“XHR”之类的字眼。回到原帖

1.因为我的浏览器默认是opera..postion为fixed 滚屏会卡..
2.以后考虑可选..
3.懒得放..
4.应该怎么改?

在google很好，到百度似乎翻到第二页就不动了

NLF：
1.因为我的浏览器默认是opera..postion为fixed 滚屏会卡..
2.以后考虑可选..
3.懒得放..
4.应该怎么改?回到原帖

回 NLF ：
1. 似乎在 Opera 下真的就只能通过自动隐藏＋稍候再现的方式绕过 Opera 的缺陷了，唉
2. 不用考虑，一定要！
3. 那你就默认允许 Conet 去放吧，可以吧？
4. 把 XHR、iframe 变成描述其特性的词，例如“高速模式”、“兼容模式”。

另，的确，百度只能翻一页。
－－－
题外话
真·原作者现身！
经过一番折腾，我知道了怎么将自己的脚本放在 Opera 用户脚本中了。
没错，就是那 EWH 。然后发现高亮的时候真的是比眨眼还快（别开心太快！），然后高亮面板的宽度被奇怪地限制住了，满屏幕的“的”字却只高亮了一个（最开始高亮了74个，切换其高亮，变成高亮11个，再切换，就只剩下一个；也不是总如此，有时高亮总正常），面板响应双击事件的宽度却扩展了。然后，就像 真·原作者 所提到的，滚动屏幕会致使面板闪动（卡起来仅比其自带的粘滞的平滑滚动好受些），然后产生的副作用就是根本没办法拖动分布图（一拖动就闪，尽管还在显示着，但却无法响应动作）……

要声明的是，除了我 EWH 独有的功能出问题外，word highlight 原版功能也出问题，就算是直接用 word highlight 原版也仍然出问题（切换高亮时高亮的个数减少），所以这只能说是 Opera 对标准的支持有问题了。

Opera 是其自行更新到的最新版 10.53 3374 。

还有，网页放大时将元素的一像素边框一边显示成两像素一边显示成一像素……如果窗口宽度刚刚比不显示水平滚动条宽一点的话，用中键滚动会发现页面仍然能水平滚动……那个“划时代的” Dragonfly 首次启动实在是太——慢——了，我这样一台一岁多点的 iMac ，干是等窗口下方那片空白出现那蜻蜓动画就等了十五秒，蜻蜓扇翅膀又用了三秒……

  ……………………
－－－
渲染“相对窗口而不是页面固定位置的元素”出现障碍这种现象，更加印证了我对 Opera 所用的渲染引擎的理解——“流式”渲染，也就是每个子元素只根据相邻的上一个元素的位置确定自己的位置的渲染方式。
这样渲染过程就会更加顺畅（所以快），元素排列的自适应性就更强（所以有独一无二的“适应宽度”功能和能更早用于各种手持设备和游戏机）；但因此丢失了元素绝对位置的信息，造成不支持对选中内容的拖曳（是的，Opera 忠实用户认为存在拖曳习惯的人需要改变习惯，否则是懒惰）、只能复制出纯文本而无法复制出超文本内容（Opera 忠实用户问：需要么？）、以及上面提到的对相对于窗口位置固定的元素渲染时出问题（不能参考已有元素的位置，于是只能在“流式”渲染外独立渲染该元素，造成闪动和效率低下）。

XHR 模式
DZ 论坛附件图片无法显示
src 的值有错
应该和file相同
就能看到图片了
iframe 模式 无问题

fiey：XHR 模式
DZ 论坛附件图片无法显示
src 的值有错
应该和file相同
就能看到图片了
iframe 模式 无问题回到原帖

我想明白了，XHR 模式就是直接请求，目标页面可以被直接操作但目标页面由于会被嵌入到当前页而导致目标页中的相对路径 url 变成相对于当前页面；而 iframe 模式是相当于仅引用，故没此问题，也不可操作目标页面。
其实既然目标页面通过直接请求拿到手之后是可以操作的，那么为所有 src、href 属性中的相对路径 url 根据请求的地址修补成绝对路径 url 并非不可能的吧？

hzhbest：
我想明白了，XHR 模式就是直接请求，目标页面可以被直接操作但目标页面由于会被嵌入到当前页而导致目标页中的相对路径 url 变成相对于当前页面；而 iframe 模式是相当于仅引用，故没此问题，也不可操作目标页面。
其实既然目标页面通过直接请求拿到手之后是可以操作的，那么为所有 src、href 属性中的相对路径 url 根据请求的地址修补成绝对路径 url 并非不可能的吧？回到原帖

xhr=xmlhttprequest
返回内容的处理javascript似乎有问题
iframe中javascript可以直接执行
某些版本的discuz似乎需要用javascript来处理页面中图片路径，否则显示某个它自己的占位符

aaaa007cn：xhr=xmlhttprequest
返回内容的处理javascript似乎有问题
iframe中javascript可以直接执行
某些版本的discuz似乎需要用javascript来处理页面中图片路径，否则显示某个它自己的占位符回到原帖

这个我知道，XHR 取得的只是目标网页的 body 区内容（没有 head 区中链接的样式表和脚本），而 iframe 则是全部。前者的操作是更容易点，后者只能在插入后再找到 iframe 内的页面再进行操作。
遇着 Discuz 那样的ex论坛，那也没办法了。

hzhbest：
这个我知道，XHR 取得的只是目标网页的 body 区内容（没有 head 区中链接的样式表和脚本），而 iframe 则是全部。前者的操作是更容易点，后者只能在插入后再找到 iframe 内的页面再进行操作。
遇着 Discuz 那样的ex论坛，那也没办法了。回到原帖

xhr的问题主要是不能跨域……
网页内容（源代码）是全的，手工做head部分链接的css、js解析应该可以
以xhr模式来处理discuz那种烂逻辑应该没问题，只是需要做额外的处理

另外，greasemonkey有个GM_xmlhttpRequest用真爽

xhr的问题主要是不能跨域……
网页内容（源代码）是全的，手工做head部分链接的css、js解析应该可以
以xhr模式来处理discuz那种烂逻辑应该没问题，只是需要做额外的处理

另外，greasemonkey有个GM_xmlhttpRequest用真爽

XHR請求的源碼不一定是完整的..例如 google搜索..google圖片..百度圖片等..

插入的內容..一般需要將XHR中的script抽掉..否則會出問題..

一般需要執行script才能獲取下一頁內容的網頁..直接用iframe方式比較簡單.

XHR請求的源碼不一定是完整的..例如 google搜索..google圖片..百度圖片等..

插入的內容..一般需要將XHR中的script抽掉..否則會出問題..

一般需要執行script才能獲取下一頁內容的網頁..直接用iframe方式比較簡單.

我还真无聊，跑去验证了google搜索……
xhr取得的google搜索就是完整的页面源代码，包括内嵌的css和js
和直接打开页面取得的源码没有区别
为什么说不一定完整？

试了试那个GM脚本.淘宝也只能自动翻一页.

如果百度用了百度++，用2楼的脚本就出现问题了...

还没有碰到过比Maxthon的supergo2好用的翻页插件

1.因为我的浏览器默认是opera..postion为fixed 滚屏会卡..

似乎 Opera 处理的方式并不如我理解的那么简单……
示例网页：
http://download.cnet.com/HTTPS-Everywhe ... =mncol;txt
实验对象：
网页底部的黑条；默认情况下其上还会附有一个提示气球；两者都是【position:fixed;】的。
实验方式：
1.鼠标在页面内任意位置，向上滚动、向下滚动，速度尽可能快；
2.鼠标在左侧页面主体内容和右侧广告之间十几像素的空隙中，重复（1.）中的动作；
3.鼠标向上拖动滚动条、鼠标向下拖动滚动条。
实验结果：
1.剧烈地在向上滚动的时候使实验对象闪动，而且闪动中实验对象的位置会出现下偏移；但向下滚动正常；
2.没（1.）那么剧烈，但仍然会出现（1.）的现象；
3.正常。
实验结论：
Opera （10.5x）可能并不如我在其他帖中说的是引擎特殊的处理方式导致对【position:fixed;】属性的元素位置处理不正确这么简单，因为鼠标是否在网页上甚至决定了问题现象是否出现。
Opera 还是像其他两款浏览器那样把内核开源吧，这样你会轻松很多——我除了“印象又差了”这样的话之外也只能这样说了。