On Thu, Jun 28, 2012 at 4:13 AM, Derric Atzrott < datzr...@alizeepathology.com> wrote:
> >I just wonder: Why do we not simply transmit the SVG image, but render a > png for an SVG-file to the browser? Historic reasons? > > I think it is because there is no good way for us to know if a browser > supports SVG images other than having a list of user-agents that do and > checking that way. > > We don't want to send an SVG image to a browser that is unable to render > it. > Someone correct me if that was wrong. > Pretty much. Back in the day (2003-2005 era) SVG support was very limited in common browsers -- only very recently did Internet Explorer 9 add it, and most Android devices still don't support it. We did some experimentation with using the <object> tag and fallbacks so that supporting browsers & browsers with plugins could get native SVG but it had negative effects, such as throwing up annoying prompts and not always showing the fallback content if there was no SVG support available. Since <object> fallback is wonky and Accept headers can't be used reliably, we'll likely end up using different tools. In these modern days, it's likely we'll end up with something like this: * load the PNG as a default * in JS, detect native SVG support and swap the SVG original in in place following similar logic as we'll probably end up using for raster images on high-resolution screens (such as the new MacBook Pro and iPad "Retina" screens, the upcoming Nexus 7 and Transformer Infinity tablets, the higher-resolution version of Microsoft's upcoming Surface tablet, etc). Sending the low-res rasterization first feels like a waste of bandwidth, but usually shouldn't be too extreme, and basically will "look and feel" like progressive loading. :) -- brion _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
