Ihor Radchenko writes:
> Christian Moe <m...@christianmoe.com> writes: > >> I think there's a better approach. Tl;dr: >> >> - A better way to have active CSS in SVG images is to link to the >> external SVG file with the <object> rather than <img> tag, as we used >> to. > > Reading the linked threads, it seems that <object> has its own > downsides. Why is it strictly better then? I'm not sure it's strictly better. The problem in the linked threads was with scaling, and I don't think it applies anymore. As I just tested in Firefox, at least, I can control the size of Gerard's SVG illustration perfectly well by setting CSS height and width attributes on an <object>. Apart from that, my reasoning amounted only to this: - <object> works as well as embedding for CSS - For Org to extract and embed the SVG means more things that can break (though I admit that it can be made a lot less fragile than the #+INCLUDE hack) and when they do break, it's an Org problem. With <object> Org just needs to properly format the tags; if it does, the rest is the browser's responsibility. - If the external SVG file is modified, with embedding all files referencing it need to be exported again for the change to take effect. With <object> linking to the external file, all that is needed is refreshing the browser. - Readable, uncluttered HTML is nice; huge, unreadable stretches of SVG aren't. Some arguments for embedding I didn't consider: - fewer http calls - It makes accessing the SVG internals with Javascript a bit easier than with <object> (the difference is just one line of JS) -- and a lot easier if you trigger Firefox's same-origin restrictions by keeping the files on a file system rather than a server. >> - Without patching Org, you can embed an external SVG file as an SVG >> island in Org HTML export simply by using #+INCLUDE. > > To be clear, I am in favor of adding "embedding" switch for ox-html in > general. It is a feature several people requested elsewhere - for all images. > #+INCLUDE is cumbersome, does not work with captions, and will generally > break Org customization relying on Org knowing what kind of object is > being exported. Fair points. Yours, Christian