Proposal talk:Inline SVG preference
 |
"Some proposals will have massive impact on end-users, including non-editors. Some will have minimal impact. What will be the impact of this proposal on our end-users?".
 The level of discussion of this proposal is: Unknown |
Impact?
Some proposals will have massive impact on end-users, including non-editors. Some will have minimal impact. What will be the impact of this proposal on our end-users? -- Philippe 01:10, 4 September 2009 (UTC)
- Direct impact will be a testing bed for users who want to try the feature out and if that goes well it can be rolled out to all of Wikipedia after an analysis of which browsers support SVG and which view Wikipedia. This might very well have to use user agent detection since IE does not yet support SVG natively. The one negative possibility is without a PNG version created by the server for all users there will be no standard base of reference (although we could easily still provide access to such a PNG). Grenavitar 14:19, 8 September 2009 (UTC)
- In a recent discussion I had about an idea along the lines of this proposal, one of the concerns brought up was that this would require servers to cache two versions of each page containing an SVG image: one version with SVG and one with PNG versions of images. Given that most existing talk pages for en-wp articles contain SVG images, this may significantly increase space requirements on servers.
- Another thing to note is that the native support is lacking for considerable parts of the SVG standard in not only IE, but Firefox 3.5 as well. For an overview of SVG by browser, see http://codedread.com/svg-support.php. The state of SVG in Firefox: https://developer.mozilla.org/En/SVG_in_Firefox. IE and FF account for over 85% of article traffic (55% and 31%, respectively; see http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm). Emw2012 14:32, 15 September 2009 (UTC)
- I think majority of figures in Wikipedia are currently photos, not graphics, and the illustrations on the user pages are all tiny, so I cannot see where this "significant increase of requirements" would come from. Browser detection problems can be eliminated by simply making this the user setting (one can switch quickly off if is forced to use the different browser somewhere in the Internet caffe). Native support comes much faster after somebody starts using the features! Audriusa 08:25, 26 September 2009 (UTC)
You can't do this "as-is". sorry.
as User:Emw2012 notes, IE does not support - and it will not support - SVG. it has VML, instead. the only possibility is, therefore, to provide an API which can map to all the options, with librsvg being the "fallback" option for server-side generation of PNGs. see Proposal_talk:Text_or_Syntax_driven_Charts,_Diagrams,_Graphs_and_more for further details on the libraries that support mapping to VML or SVG, client/browser-side. also there's http://excanvas.sf.net which emulates SVG for IE, re-mapping everything to VML. all of these options are dreadfully slow, compared to modern browsers supporting SVG Canvas. Lkcl 18:49, 12 October 2009 (UTC)