Problem: SVG files are currently rendered out as PNG files on pages that use the image.
Proposed solution: Embed the SVG into the page output, only using PNG as a fallback on devices that don't support SVG.
Who would benefit: Readers on various devices when zooming in on the image within an article.
More comments: Currently SVG files are rendered out in a fixed resolution PNG file which, when scaled, suffers from the usual issues when zooming into a raster image. Embedded SVG (allowing clients/web browsers to render the images instead) would allow these images to be scaled infinitely with the only restriction being the client/browser.
I wonder how worthwhile it would be to give users the option to forcibly use the PNG fallback for individual images if performance improvements are necessary, such as [[File:Example.svg|forcepng]]. -BRAINULATOR9 (TALK)19:52, 23 January 2023 (UTC)[reply]
We can't rely on that. If someone adds a 28MB SVG to the frontpage... there has to be some sort of technical protection against that. Also we have the problem with fonts not being consistent across browsers, so for that you also need some sort of processing before you can have files included (these are details which are already mentioned in the relevant tickets). —TheDJ (talk • contribs) 19:54, 23 January 2023 (UTC)[reply]
Just a clarification. I think this wish is very much doable. But it's going to be a little bit more involved than 'just switch to the original svg'. Will easily take a few weeks of work. —TheDJ (talk • contribs) 23:48, 26 January 2023 (UTC)[reply]
Huh? I'm talking about, if this proposal is implemented and SVGs default to being rendered as SVGs, then the option should exist to use the PNG format as a fallback. -BRAINULATOR9 (TALK)18:16, 16 February 2023 (UTC)[reply]
@Brainulator9: I understand what you're asking for, but is there a reason someone concerned about that couldn't just simply upload a PNG rendering of the SVG for such a use-case? I think @TheDJ and I are thinking of technical restrictions to (as TheDJ suggested) limit gigantic SVG files from being sent as-is. But if there's some edge-case where a PNG is desired, simply uploading a PNG and then the SVG source for future editors to make changes to as-needed would suffice, no? —Locke Cole • t • c18:41, 16 February 2023 (UTC)[reply]
I definitely think there should be a cutoff for how large of an SVG we'd want sent to clients. For all SVG < 32KB *or* where the SVG is smaller than a PNG, I'd presume we just send the SVG. For situations where the SVG is larger than 32KB AND the PNG is smaller, then it might make sense to send the PNG still. 32KB is a purely arbitrary number, I'd hope we'd look at the existing average sizes of SVG files throughout the projects and do some data crunching to come up with a number that makes sense. —Locke Cole • t • c19:59, 23 January 2023 (UTC)[reply]
There's a script I used to test how native SVGs would work on Wikipedia... and they worked okay unless they were detailed geo maps with many tiny polygons, in which case large parts of the wikipage would stop rendering, text and pics. This is the code for your common.js: //mw.loader.load( '/w/index.php?title=User:Opencooper/svgReplace.js&action=raw&ctype=text/javascript' );ponor (talk) 21:27, 23 January 2023 (UTC)[reply]
Why can't Wikipedia clean up svg pictures before uploading them to the server? There are resources with an open license such as SVGo. This will ensure the safety of this format of images. It is also possible to make a limit on the size of uploaded svg for example in 56Kb (talk) 12:07, 26 January 2023 (UTC)[reply]
Limit the size of the SVG is not a good idea. Or at least if limited, should be some reasonable big number (at least 25-30 MB). I have some maps in svg that require details and easily go over 10-15 MB. Ikonact (talk) 08:33, 27 January 2023 (UTC)[reply]
It's will be awesome, because SVG is can contain not only vector graphics, but also animated and also interactive graphics. Although, it was a security and peroformace issuie if WP will embed every SVG image. Maybe, we need special tag or something for svg-images, that checked for issues to decide, embed this image into page or make png thumbnail.--Tucvbif (talk) 15:38, 11 February 2023 (UTC)[reply]
I understood embedding SVGs to mean "using the original SVG wherever PNG thumbnails are currently being used". That being said, there's no risk of interactive graphics screwing with the page, as an SVG's code needs to be embedded directly into the page in order to respond to user activity. Moreover, this feature wouldn't introduce new security issues, as WP already blocks SVG uploads that contain scripts and other "problematic" content. Alhadis (talk)
Comment : I Oppose because it would ruin support of direct liking of a CC media, some people use CC photos as references in other sites (mostly forums), on those sites SVG is not even close to be supported as PNG is
SVG has been around for decades. Every major browser supports it. I'm not sure opposing for how non-Wikimedia sites use our content is even a valid reason to oppose here, as this is a wishlist survey for the community here. Is there a reason direct SVG would be a net negative for the Wikimedia community? —Locke Cole • t • c18:38, 14 February 2023 (UTC)[reply]
Oppose —2dk (talk) 18:58, 10 February 2023 (UTC)
Support Tol (talk | contribs) @ 20:45, 10 February 2023 (UTC)
Strong support Alhadis (talk) 13:17, 11 February 2023 (UTC)
It is doubtful --Tucvbif (talk) 15:38, 11 February 2023 (UTC)
Comment : I Oppose because it would ruin support of direct liking of a CC media, some people use CC photos as references in other sites (mostly forums), on those sites SVG is not even close to be supported as PNG is
