Would a JS zoom button be an acceptable alternative, similar to Dschwen's ZoomViewer?

https://tools.wmflabs.org/zoomviewer/index.php?f=Xeromphalina_setulipes.jpg&flash=no

That is already tracked by https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/167. I gather that would be much easier than handling browser zoom on all browsers.

(In reply to Tim Starling from comment #1)

Would a JS zoom button be an acceptable alternative

How? Sure, it's possible to hijack Ctrl+Plus and Ctrl+Mouse wheel, but you can not hijack the zoom function if it's accessed via the browsers toolbar or menu. I think the request is very, very simple: Let the users use the browsers build in zoom function. That's it. That's what everybody is used to. That's what the users are asking for in the discussions.

I am not suggesting hijacking ctrl-plus or ctrl-mousewheel, I am suggesting making something like the popular ZoomViewer tool, which is linked from Commons description pages for all files over 2 Mpx. In ZoomViewer, pressing Ctrl-plus just enlarges the text, it does not enlarge the image. To enlarge the image, you click the "+" button.

I am not saying that I don't understand what you are asking for, I am asking if you think this would be an acceptable alternative, since what you are asking for is complicated to implement.

Personally, I never use ctrl-plus for zooming images on WMF projects, since there are much better ways to zoom, for example the "other resolutions" link on the image description page, which allows enlargement without pixellation. Maybe you mean everybody except me?

(In reply to Tim Starling from comment #3)

I am asking if you think this would be an acceptable alternative

Having a tile-based viewer is an other request that already haves it's own reports here on Bugzilla, as far as I know. It would be great to have that, sure, but it's not a replacement for a straight Ctrl+Mouse wheel. Even Google Maps supports both. Try it.

what you are asking for is complicated to implement.

The problem is that it feels like the viewer is actively blocking a browsers core feature. Users don't really care for technical reasons - and should not.

there are much better ways to zoom, for example the "other resolutions"

I don't say people are not using other ways. But often it's enough to have a slightly blurred low-res version zoomed in with Ctrl+Mouse wheel.

Maybe you mean everybody except me?

I'm not expressing a personal opinion here. I try to tell you what I have read on many different talk pages. I'm really sorry if my English is not kind enough.

OK, understood. Thanks for the report and the suggestion to look at Google Maps.

I note that Google Maps has interface text overlaying the image, so there's a relatively sensible action to take when the browser asks for both to be enlarged. Like MMV, Google Maps appears to respond to the resize event by reducing the size of the canvas so that it will still fit on the screen.

(In reply to Tim Starling from comment #1)

I gather [JS zoom] would be much easier than handling browser zoom on all
browsers.

I am not sure about that; but you need JS zoom anyway for large images because the full image needs to be swapped out for tiles; and implementing both browser zoom handling and tile-based zoom seems like a waste of effort.

(In reply to Tim Starling from comment #5)

I note that Google Maps has interface text overlaying the image, so there's
a relatively sensible action to take when the browser asks for both to be
enlarged. Like MMV, Google Maps appears to respond to the resize event by
reducing the size of the canvas so that it will still fit on the screen.

As far as I see Google Maps does exactly the same thing as MediaViewer: the text gets larger and the image gets more blurry. The only difference being that they only have a tile-based zoom already so don't try to match the full map to the full viewport after a resize.

Anyway, there might be a different layout and/or different JS fit-to-viewport implementation which works better with native zoom; that would take some experimentation. I would hold that off at least until we decide whether to go with the minimal version without any scrolling ( https://gerrit.wikimedia.org/r/#/c/150585/ ) or the current one, since the constraints on layout would be very different.