Wikimedia Meta-Wiki

Community Wishlist Survey 2019/Archive/Option to embed SVGs as SVGs

< Community Wishlist Survey 2019‎ | Archive
(Redirected from Community Wishlist Survey 2019/Multimedia and Commons/Option to embed SVGs as SVGs)

Option to embed SVGs as SVGs

 N Outside the scope of Community Tech

  • Who would benefit:
    1. graphic designer (SVG)
    2. all Authors that like to use SVG-Files (to use them they have be rendered correctly)
  • Proposed solution: allow an option like [[File:Filename.svg|thumb|vector]] to allow embedding as SVG just for special files, for files that are whitelisted.

Discussion

We want ensure an uniform rendering, therefore it is necesarry that the SVGs are rendered by Wikimedia, but for view problematic files that might be usefull to be rendered by the users browser. For small files it would even decrease the download-size. If a file contains text it should also contain fallbackfonts for Windows/Linux/Mac.  — Johannes Kalliauer - Talk | Contributions 21:19, 29 October 2018 (UTC)[reply]

Small note that embedding an SVG is a specific technique that is different from using SVGs as images (instead of the PNG thumbnails, which you likely mean). I have added the most closely related ticket that I could remember to your proposal, T134455. This change does potentially conflict with translatable SVGs btw, as browsers use the browser instead of the HTML content language to render SVGs. Additionally, there likely has to be some limit on very complext SVGs like the one of our entire earth, which would cause significant strain on the client side. I think both problems are surmountable as part of this wishlist effort. —TheDJ (talk • contribs) 10:30, 30 October 2018 (UTC)[reply]
Displaying SVGs as svg files has been an ongoing discussion within the technical community and there are, unfortunately, several potential issues with that present us with blockers at least for the short-term. Most notably:
  • Browser support is lacking, and where it exists it is non consistent. This isn't a complete blocker to implement SVGs but it definitely makes the task a lot harder and requires architectural thinking about how and when to do fallbacks.
  • Performance considerations: While SVGs can be smaller than their PNG equivalent, they can also be massively bigger; an example is the Wikipedia logo, where the globe and logo drawings are significantly larger than the scaled-down thumbnails. Even if we solve the issue of serving "fallback" pngs, we'll need to make sure that these fallbacks take into account file sizes, which is another fairly elaborate architectural consideration.
  • Security considerations: We disable some SVG features in the server-side renderer, and we automatically detect security or privacy-sensitive features on SVG upload, but upload detection is not as strong as it should be to recognize real potential security dangers. There are certainly features that are okay to do server-side but would present a serious privacy risk if done on the client. Updating security concerns on upload would also have to then be done on all existing SVGs which is a very expensive operation, but we will have to make sure we keep our security and privacy up to date.
All of these (an incomplete list, but fairly representative) are not end-all-be-all for SVGs, but they definitely show that the request as it stands right now is very complex and requires quite a number of architectural changes to be done for us to start considering potential solutions. Some of these are in progress, and some we'll need to continue discussing and work on, including, probably, some technical RfCs, to hash out the best long-term solutions that maintain the proper performance, browser support and security/privacy considerations that we're requiring from all products.
That said, @JoKalliauer: maybe we can try and scope this down a bit? Maybe identify the biggest bugs, or hurdles, and get the wish to concentrate on solutions to these? We can probably tackle a couple of those bugs or some of the features that are requested, within the scope of what the team can do in the wishlist, without having to count on the pretty massive architectural (and security/etc) concerns that a full blown SVG-display support will require. MSchottlender-WMF (talk) 21:06, 31 October 2018 (UTC)[reply]

My recommendation is that JoKalliauer file a Phabricator task for this idea. This will provide a permanent place for us to explore the technical issues and document the justifications. At present, I don't think this proposal has been developed sufficiently to be ready for voting. -- Tim Starling (WMF) (talk) 05:34, 1 November 2018 (UTC)[reply]

An epic task for this can be found at phab:T5593. -- NKohli (WMF) (talk) 19:52, 1 November 2018 (UTC)[reply]
@TheDJ: Thanks for your answer and adding the Phabricator task  : I thought about both problems already before you mentioned them, but as you said they are approachable.
  • language-switch: Files with a language-switch should be embedded as png. I don't know any file that shows a librsvg-bug and has a language-switch. (except: File:Well_to_Wheels_(kWh).svg this had a librsvgbug and afterwards it got a language-switch.) For the rare case of a combination of a librsvg-bug and language-switch it might be usefull to offer several svgs, simmilarly as now we offer several pngs, but thats far beyong my whish.
  • Complex SVGs (SVGs above ~512KB) should not be embedded as SVGs (Always embedd SVGs above 1MB as PNG, even if the user specifies it differently)
@MSchottlender-WMF:
  • Browser support might be lacking, but is generally much better than librsvg (check for example https://github.com/RazrFalcon/resvg#svg-support ) I would say librsvg has more than 10times more bugs than Chrome or Firefox and even Internet Explorer is much better. Or what do you mean with Browser support is lacking? (f.e. common Examples)
  • Performance considerations: It should only be available for problematic SVG-files not for all. Patroller might whitelisting specific SVGs for allowing rendering SVGs on client-side (users might be able to deactivate that in Special:Preferences), like for animated SVGs (f.e. File:Morphing_SMIL.svg).
  • Security considerations: If Patroller whitelist SVGs for allowing rendering specific SVGs I don't see a big security issue. (But SVGs have a lower security-risk than PDFs, but xlink:href to external gets blocked anyway)
  • Maybe identify the biggest bugs, or hurdles: There are too many, that is not good idea[clientRendering 1]. Above I quoted 20 Bugs that would be solved with client-side-rendering. (phab:T20463, does not have any woraround, phab:T32033 needs commas but phab:T194192 needs spaces, phab:T35245 is the most common bug, phab:T35245 does occour when converting PDFs to SVGs in Inkscape; phab:T36947 read the last 4 request on w:Wikipedia:SVG help or w:de:Wikipedia:Probleme_mit_SVGs#Die_Abstände_von_Buchstaben_stimmen_nicht and you know this is a problem; phab:T43424 Wikipedia is known for this bug[1] (Since it does not apper on browsers); phab:T55899 is the second most common bug).
If not all common browser does not support a feature of svg, there is no need to support this feature! (except language-switch is not fully/uniform supported by all browsers, but librsvg also has it's problem with language-switches).
@Tim Starling (WMF): I think phab:T5593 and phab:T134455 are enough, or is something missing?
I think the proposal now developed enough, or what is missing? If you have doubts tell me them, I'm shure I'll already thought about a solution. (I do not quote all problems, which already have a solution since they are not problems any more.)
@NKohli (WMF): Thanks for adding this Phabricator task.  
 — Johannes Kalliauer - Talk | Contributions 21:56, 1 November 2018 (UTC)[reply]
No, they are not enough, I mean a task specifically for the file=svg parameter. -- Tim Starling (WMF) (talk) 22:01, 1 November 2018 (UTC)[reply]
I added a specifically task for the file=svg-parameter: phab:T208578,  — Johannes Kalliauer - Talk | Contributions 18:07, 4 November 2018 (UTC)[reply]
@JoKalliauer: I understand your proposed solutions and the frustration with the existing insufficient technological answer. However, adding the ability to display svgs as svgs will require quite a lot of architectural changes, some of which I mentioned above, and some require deeper decisions about how to handle security and performance with given images and with making sure that the upload and display technologies are synchronized in requirement and spec. It's not that we think this is a bad idea, it's that the path to make this happen looks like it's quite very much too big for the scope of a wishlist wish.
However, I do believe we can help both fixing some of the bugs and, perhaps, starting some of the required tasks to get to the ultimate goal of having this enabled on wikis -- which is why I asked that we try and trim this down, or try to find a way where this wish is more feasible, given the reality of what the team can provide. MSchottlender-WMF (talk) 02:08, 14 November 2018 (UTC)[reply]

I like this proposal a lot but mostly of different reasons than the rendering-bugs. All the benefits of vector grafics get lost if we convert them to pngs serverside. Server-side-rendering makes sense for complex graphics but not for simple graphics. Maybe you can add this as additional point to the description. Also I think that instead of [[File:Filename.svg|thumb|file=svg]] we should use [[File:Filename.svg|thumb|vector]]. It's easier and more to the point. -- MichaelSchoenitzer (talk) 23:51, 7 November 2018 (UTC)[reply]

Annotations
  1. ↑ It might be better to allow change the renderer to Inkscape(very slow, but very precisse) or to resvg(fast processing, fast developing but still almost as buggy as librsvg). See phab:T40010,mediawiki:SVG Benchmark,current SVG-Rendering-benchmark for details.

Hi JoKalliauer: As MSchottlender-WMF said above, this proposal is too big for the Community Tech team to take on. It looks like you're talking to the right people now, and there's some conversation happening on phab:T208578 and the related tickets. I'm going to archive this proposal. Thanks for participating in the survey. -- DannyH (WMF) (talk) 19:40, 15 November 2018 (UTC)[reply]

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2019/Archive/Option_to_embed_SVGs_as_SVGs&oldid=18603549"