Page MenuHomePhabricator

Add experimental option for direct SVG output via srcset
Closed, DeclinedPublic

Description

Per https://phabricator.wikimedia.org/T134409#2266050 it appears to work reasonably well to specify an SVG for client-side rendering in an <img> while retaining the PNG fallback behavior by putting the SVG in the srcset attribute with 1x density instead of listing out additional 1.5x and 2x PNGs. For modern browsers with native srcset support, this will override the rasterized PNG from the src attribute, without the PNG ever being loaded.

This may require fixing the jquery.hidpi srcset polyfill for older browsers to check at runtime for SVG-in-img support, to avoid accidentally loading an undisplayable SVG. (Browsers that do support SVG but not srcset would still load the PNG before the polyfill has a chance to run.)

Event Timeline

For some reason the project tags got lost during submission; re-adding.

Restricted Application added a subscriber: Steinsplitter. · View Herald Transcript

Change 287074 had a related patch set uploaded (by Brion VIBBER):
[WIP] Experimental $wgSVGClientSideRendering option

https://gerrit.wikimedia.org/r/287074

I was wondering.. Since this is on the drawing board now. Would it not be smart to tackle T49578: Score should output SVG first ? Way more isolated testing ground, that could use this same solution approach, yet less likely of having the problem of "what do we do with 50MB SVGs" ?

There must be a simple size-check. As I suggested before, there could also be a SVG control patrol for a SVG ready system.
Or better on the other hand, a system to mark "bad" SVG (to exclude).

Don't forget that our use of the "lang" feature in SVGs differ from the w3c standard, as implemented by browsers. In addition to blacklisting large SVGs we need to blacklist SVGs using the language selector feature.

Ah, good catch -- that'll use browser language not site language I suspect. Needs some investigating.

Its probably something that could be fixed in a post-processing layer to the svg.

@TheDJ - regarding Score SVG output, T49578 has been merged, but is still open. Not sure what happens now, but this would be a good test for using img srcset, since that's what we implemented in Score.

This option is very clever. It was a way to efficiently offer both PNG and SVG.

However, given that today reasonable browsers support SVG (see the now closed T134410), WMF need not worry about dual support: WMF can supply SVG and not worry about providing a PNG fallback for browsers that lack SVG support.

Consequently, I would close this task as declined. It was a great idea, but now the browser world has adopted SVG, so the option is no longer needed. If WMF puts the SVG in the src attribute, then the img element will display that SVG.

That's all well and good, in that case, how are we to advance T5593 which has been languishing since 2005? That's nearly twenty years. I would like to see SVG Score output hopefully some time before the sun runs out of hydrogen and engulfs our planet in a fiery apocalypse.

That's all well and good, in that case, how are we to advance T5593 which has been languishing since 2005? That's nearly twenty years. I would like to see SVG Score output hopefully some time before the sun runs out of hydrogen and engulfs our planet in a fiery apocalypse.

Advancing SVG support should be debated on T5593. This topic is about exploiting srcset.

Many want SVG support: https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2023/Multimedia_and_Commons#Native_SVG_support

Should we close this ticket, given we now have wgSVGNativeRendering and related settings merged to master on T208578?

Should we close this ticket, given we now have wgSVGNativeRendering and related settings merged to master on T208578?

Yeah, based on the other routes discussed in T208578 and friends, I don't think using srcrset is going to add much benefit to anyone. We don't really support any browsers that do NOT support native SVG any longer (which this could have helped with)