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

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.


Reply via email to