​[Feature Request] Add mobile pinch-to-zoom support

[cnlnr]

💡 Feature Description

Please add support for mobile pinch-to-zoom gestures (touch scaling) in prism-code-editor.

Currently, the editor lacks support for native two-finger pinching/zooming on mobile screens, making it impossible to scale or zoom in on code snippets when needed.

---

🎯 Use Case / Motivation

When accessing the editor on mobile devices (or within a desktop-simulated viewport like <meta name="viewport" content="width=1280">):

1. Code text can be too small to read on smaller screens.
2. Users cannot use the standard mobile two-finger pinch gesture to zoom in on code or zoom out for a broader view.

Adding this feature will significantly improve readability and accessibility for mobile users and WebView environments.

---

🛠️ Requested Behavior

• Allow users to scale/zoom the editor content using native mobile pinch-to-zoom gestures.
• Ensure touch events don't block mobile browser gesture scaling.

---

📷 Environment

• Platform: Mobile Browsers (iOS Safari / Android Chrome / Android WebView)

[jonpyt]

Mobile browsers already allow users to pinch and zoom in on the page (unless you have a <meta name="viewport"> with maximum-scale=1, although iOS will ignore this). If the font size is too small, they can just zoom in on the page.

When accessing the editor on mobile devices (or within a desktop-simulated viewport like ):

1. Code text can be too small to read on smaller screens.
2. Users cannot use the standard mobile two-finger pinch gesture to zoom in on code or zoom out for a broader view.

Adding this feature will significantly improve readability and accessibility for mobile users and WebView environments.

If users cannot pinch and zoom in on your page, then maybe something is wrong with your <meta name="viewport"> tag?

Controlling the font size of the editor should be the role of the application developer, not this library. You can configure the font size with CSS on .prism-code-editor , and since almost all the styles use em units, the editor will just scale perfectly to fit the font size. If you're worried about the font size being to small, maybe add an "editor font size" setting to your web page or something?

[cnlnr]

What I mean is, it works like a map: code zooms and pans, but line numbers are fixed on the left and never move horizontally.

[cnlnr]

Mere scaling feels stiff and unlike a map, without zooming centered between two fingers.

[jonpyt]

The current layout does not make it possible to scale the editor's font size without scaling the line numbers and editor padding as well. Changing the layout to make this possible would be a breaking change (probably a rather big one as well). This is also very difficult to implement in a usable manner. Ideally, the code won't shift under your finger while pinching, which would require updating the scroll position of the content.

Mere scaling feels stiff and unlike a map, without zooming centered between two fingers.

It would, but why isn't the native pinching implemented in mobile browsers sufficient? Yes, the line numbers won't be in a fixed position when pinching in the browser, but this is not necessary to make the content legible.

[cnlnr]

https://dev.to/cnlnr/i-solved-text-position-offset-during-pinch-to-zoom-in-mobile-code-editors-2p0c

[jonpyt]

https://dev.to/cnlnr/i-solved-text-position-offset-during-pinch-to-zoom-in-mobile-code-editors-2p0c

I totally forgot the zoom property exsists. That's a bit better than scaling the font size. I created two extensions that add pinch to zoom. One changes the font size, while the other changes the zoom property. https://stackblitz.com/edit/vitejs-vite-a4ffmmn5?file=src%2Fzoom2.ts,src%2Fzoom.ts

Note that the extension using zoom requires the following CSS to work:

.show-line-numbers::before,
.pce-wrapper {
  zoom: var(--zoom);
}

Try both and let me know what you think. I might consider making it an official extension, but I'm not sure.

[cnlnr]

The zoom approach is noticeably smoother with smaller files. As the code grows (around 1k lines), both methods become very laggy, though scaling font size only offers a slight performance edge over zoom.

Additionally, my personal preference is to fix the scaling origin at the top-left of the code box, rather than zooming centered between the two fingers.

[jonpyt]

The zoom approach is noticeably smoother with smaller files. As the code grows (around 1k lines), both methods become very laggy, though scaling font size only offers a slight performance edge over zoom.

The zoom property is more robust since using px units when changing the --padding-inline and --number-spacing CSS variables won't cause any issues then. There are some decorative elements like borders and indentation guides that use px units for their widths, although one could prefer that these don't scale. The customCursor() extension also doesn't update properly with font-size. I would probably recommend the zoom property.

Additionally, my personal preference is to fix the scaling origin at the top-left of the code box, rather than zooming centered between the two fingers.

Well that makes the math for updating the scroll much simpler. I changed the zoom version to have the scaling origin at the top left.
https://stackblitz.com/edit/vitejs-vite-a4ffmmn5?file=src%2Fzoom2.ts,src%2Fzoom.ts (still the same link)

I also updated the font-size version to using a CSS variable, so the following CSS is needed to make it work:

.show-line-numbers::before,
.pce-wrapper {
  font-size: var(--font-size);
}

[cnlnr]

This updated code is much smoother because it explicitly locks scrolling during the pinch gesture

Also, I noticed a new issue: with large files and low frame rates, rapid pinching causes the code content to drift off-center. Regardless of the version

import type { BasicExtension } from 'prism-code-editor';

const distance = ([a, b]: TouchList) =>
  Math.hypot(a.clientX - b.clientX, a.clientY - b.clientY);

const clamp = (value: number, min: number, max: number) =>
  Math.min(Math.max(value, min), max);

export const pinchToZoom = (minZoom = 0.5, maxZoom = 4): BasicExtension => {
  return editor => {
    const container = editor.container;
    let prevDist: number;
    let curZoom = 1;
    let isPinching = false;

    container.style.touchAction = 'pan-x pan-y';

    const stopPinch = (e: TouchEvent) => {
      if (e.touches.length < 2 && isPinching) {
        isPinching = false;
        container.style.overflow = '';
      }
    };

    container.addEventListener('touchstart', (e) => {
      if (e.touches.length > 1) {
        isPinching = true;
        prevDist = distance(e.touches);
        container.style.overflow = 'hidden';
      }
    }, { passive: false });

    container.addEventListener('touchmove', (e) => {
      if (e.touches.length < 2 || !isPinching) return;
      if (e.cancelable) e.preventDefault();

      const newDist = distance(e.touches);
      const newZoom = clamp(curZoom * newDist / prevDist, minZoom, maxZoom);
      const f = newZoom / curZoom;

      prevDist = newDist;
      if (newZoom === curZoom) return;

      curZoom = newZoom;
      container.style.setProperty('--zoom', String(curZoom));
      container.scrollTo(f * container.scrollLeft, f * container.scrollTop);
    }, { passive: false });

    container.addEventListener('touchend', stopPinch);
    container.addEventListener('touchcancel', stopPinch);

    window.addEventListener('touchmove', (e) => {
      if ((isPinching || e.touches.length > 1) && e.cancelable) {
        e.preventDefault();
      }
    }, { passive: false });
  };
};

[jonpyt]

{ passive: false } is not necessary for the touchstart listener. I would also avoid adding an event listener to window since that won't be cleaned up when calling editor.remove() which can result in memory leaks and performance degradation if many editors are created and removed.

Also, I noticed a new issue: with large files and low frame rates, rapid pinching causes the code content to drift off-center. Regardless of the version

I don't know what would cause this. Maybe the whole pixel rounding of the scrollLeft and scrollTop properties?

[jonpyt]

I updated the StackBlitz example. It now has a single pinchToZoom extension with a configurable zoom point as a third parameter to the function. By default it's centered between the fingers, but by passing true to the third parameter, it's fixed top left intead.

The overflow: hidden while scrolling and touch-action: pan-x pan-y as you suggested does seem to have made the zooming slightly smoother.

[cnlnr]

I don't know what would cause this. Maybe the whole pixel rounding of the scrollLeft and scrollTop properties?

I think that once a project becomes complex, it encounters performance issues, making it impossible to continue adding more features. Atom is an example. This may be why many large-scale projects do not use scripting languages. Maybe consider switching to Rust? What do you think of my perspective?

[jonpyt]

Maybe consider switching to Rust? What do you think of my perspective?

The low framerates when zooming on large documents are caused by costly layout and style calculations in the browser. The solution to this is not Rust and Webassembly. Better performance here would require virtualization to reduce the number of elements in the DOM, which would speed up the layout/style calculations. This isn't implemented due to the increased complexity this would require. This library is meant to be a lightweight alternative to Codemirror/Monaco when those libraries are overkill. If you're worrying about performance on large documents, then Codemirror is probably a better fit.

[cnlnr]

No, what I mean is that when developing a project with scripting languages, once it reaches a certain scale, it inevitably becomes laggy. Once it gets laggy, you can't easily add more features. This might be the reason why so many people switch to lower-level programming languages, so that they can build larger and more complex projects. I just wanted to see what you thought of my perspective.

[jonpyt]

Yes. One great example is that historically most of the tooling in the JavaScript ecosystem has been written in JavaScript. As projects grew, so did the build times. Recently, we've seen most of the JavaScript tooling being migrated to languages like Rust and Go to keep build times and linting performance in check for large projects. These types of tools will all struggle given a large enough project. Using a faster language just moves the limit.

I really don't see how this is relevant to Prism code editor though. The limit is not caused by JavaScript, but by the DOM and the browser.