使用 jquery 并行滚动文本区域和网页

发布于 2024-08-31 14:01:19 字数 417 浏览 5 评论 0原文

这既是一个概念性问题,又是一个操作方法问题:

在 wiki 格式或非所见即所得编辑器场景中,您通常有一个用于内容输入的文本区域,然后有一个辅助预览窗格来显示结果,就像 StackOverflow 一样。这工作得相当好,除了大量的文本,例如整页维基等。

我有一个概念,我想要关键的反馈/建议:设想一个两窗格布局,预览内容在左侧,占据页面的约 2/3,右侧的文本区域占据页面的约 1/3。即使用户滚动浏览器窗口,文本区域也会浮动,以保持在视图中。此外,如果用户滚动文本区域内容,假设它超出了文本区域的框架大小,则页面将滚动,使得文本区域中当前显示的内容与浏览器窗口中显示的内容同步/平行。

我正在想象一个 wiki 场景,在标记和预览之间来回切换是令人沮丧的。我很好奇别人怎么想;那里有这样的东西吗?关于如何攻击此功能有什么建议(最好使用jquery)?

谢谢

This is both a conceptual and how-to question:

In wiki formatting, or non WYSIWYG editor scenarios, you typically have a textarea for content entry and then an ancillary preview pane to show results, just like StackOverflow. This works fairly well, except with larger amounts of text, such as full page wikis, etc.

I have a concept that I'd like critical feedback/advice on: Envision a two pane layout, with the preview content on the left side, taking up ~ 2/3 of the page, and the textarea on the right side, taking up ~ 1/3 of the page. The textarea would float, to remain in view, even if the user scrolls the browser window. Furthermore, if the user scrolls the textarea content, supposing it has exceeded the textarea's frame size, the page would scroll so that the content presently showing in the textarea syncs/is parallel with the content showing in the browser window.

I'm imagining a wiki scenario, where going back and forth between markup and preview is frustrating. I'm curious what others think; is there anything out there like this? Any suggestions on how to attack this functionality (ideally using jquery)?

Thanks

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

羞稚 2024-09-07 14:01:19

任何标记语言或简化标记语言(如 wiki 符号)都会因格式而与输出不同,因此按相同数量的像素或按一定比例滚动文本区域和格式化输出将始终松散同步。

给他们用户两个滚动条然后放弃......

或者

我有一个主意给你。它基于根本不滚动预览,而是仅从当前编辑的部分生成预览的想法。

找出文本区域中可见的内容是我的第一个想法,但它不会比同时滚动两个视图更可靠。

您可以做的是获取文本区域中的当前光标位置(可以完成。有一些浏览器问题)
然后获取当前位置前后的一些 n 个字符,四舍五入为整行,并从中生成预览。您可以每 1 或 2 秒检查一次光标位置是否发生变化,如果发生变化则更新预览。

n 取决于文本区域的大小。

优点:

没有同步问题,只需生成较大文本的一部分

缺点:

仅在用户移动文本光标时更新。

你可以把它作为一个功能...文本区域将是页面的主要部分,预览 div 将浮动。

如果您需要更多详细信息或帮助,请在评论中询问。

Any markup language or simplified markup language like the wiki notation will differ from the output due to the formatting, so scrolling both textarea and formatted output by the same ammount of pixels or with some proportions will always loose sync.

Give them users two scrollbars and give up...

or

I've got an idea for You. It's based on the idea of not scrolling the preview at all, but generating it only from a currently edited part.

Finding out what is visible in the textarea was my first idea, but it won't be any more reliable than scrolling both views together.

What You can do is get the current cursor position in the textarea (can be done. has some browser issues)
Then get some n characters before and after the current position rounded to full lines and generate preview from that. You can check for cursor position change every 1 or 2 seconds and upate preview if it changed.

n depends on the textarea size.

pros:

no sync problems, need to generate only a part of a larger text

cons:

updates only if user moves text cursor.

You could make it a feature... The textarea would be a dominant part of the page and the preview div would float by.

If You need more details or help just ask in comments.

慕巷 2024-09-07 14:01:19

看起来是个好主意!您可能有一个 #preview 和一个 #input,并使用一个简单的事件更新预览:

document.getElementById('preview').addEventListener('change', update, false);

Looks like a great idea! You might have a #preview and a #input, with the preview updated with a simple event:

document.getElementById('preview').addEventListener('change', update, false);
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文