use <img> tags instead of <object> tags for svgs

[rfindler]

I am not completely sure of the ramifications of this change for browsers and am hopeful that someone knowledgable might be able to chime in here.

I do know that this speeds up the rendering of some of @tov 's lecture notes considerably.

[soegaard]

The relevant StackOverflow question: https://stackoverflow.com/questions/4476526/do-i-use-img-object-or-embed-for-svg-files

Things to try out:

Does embedded bitmaps work on WebKit browsers?

 Does interactive svgs work?

This MDN article has some pros and cons: https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimedia_and_embedding/Adding_vector_graphics_to_the_Web

[bennn]

cc @blerner

[blerner]

https://caniuse.com/#feat=svg-img

[blerner]

Anecdotally, HTDP2e used SVGs for its end-of-example little black boxes. I replaced those with some simple CSS and Matthias included that. It sped up the rendering of parts of the book from O(1 minute) to O(2 seconds).

Unless you're trying to programmatically manipulate the SVGs using javascript (which I don't think is the point of scribble), or have them be interactive, I don't think there's a benefit to object vs img tags.

[rfindler]

@soegaard, when you ask about embedded bitmaps in WebKit browsers, are you thinking of an SVG like this one? It seems to work for me in Safari on OS X 10.11.

[rfindler]

As for interactive svgs, as far as I can tell, that requires some javascript to manipulate the svg in order to work? If that's the case, then I think we're probably safe to not worry about it too much. One thing we could do is add an extra field (style, perhaps?) to the image-element that said to use <object> for svgs instead of <img>.

Would that be better/safer?

[soegaard]

2017-11-07 14:53 GMT+01:00 Robby Findler notifications@github.com:

@soegaard https://github.com/soegaard, when you ask about embedded bitmaps in WebKit browsers, are you thinking of an SVG like this one https://github.com/racket/scribble/files/1450196/pict_133-svg.txt? It seems to work for me in Safari on OS X 10.11.

Yes. I mentioned embedded bitmaps because the StackOverflow answer listed those as a concern.

/Jens Axel

[soegaard]

As for interactive svgs, as far as I can tell, that requires some javascript to manipulate the svg in order to work? If that's the case, then I think we're probably safe to not worry about it too much. I think (but haven't checked) that css is enough. @mbutterick ?

One thing we could do is add an extra field (style, perhaps?) to the image-element that said to use

[soegaard]

Here is an example of an animated svg: https://jonsuh.com/blog/animate-svg-with-css/

[rfindler]

Ah, okay. Thanks!

[rfindler]

re animated svgs: I think that someone would have to be doing fairly special things to successfully use animated svgs with scribble. I agree that it is possible that someone is doing that, and it is possible that a change like the one I propose could break that code.

It seems unlikely, tho, but maybe I'm not being conservative enough?

[mbutterick]

FWIW I used SVGs in object tags for the animated lettering on the RacketCon 2016 page (though with Pollen not Scribble).

As a concurrence to @blerner: within a web browser, an object is conceptually & semantically a different thing than an img. If there was a time when SVGs had to be put inside an objectas a workaround, that should be seen as one of the many dumb hacks made necessary by lazy browser engineers. It should not be preserved in the face of progress.

Along those lines, rather than adding an extra field to image-element, consider adding a new struct — say, object-element — designed for the purpose. Otherwise, two distinct concepts are being smushed together in the API, again because of lazy browser engineers.

[rfindler]

So it sounds like people tentatively think that changing the way image-element renders is a good idea and that adding a field to it to select for <object> is a bad one, which makes sense to me. If that's right, then perhaps it is time to take this commit onto master? Does anyone think it is unwise?

We could also wait until the next release branch is created to give the maximum amount of time to discover problems?

[mflatt]

Merged (because I needed this - thanks!), but not included in the v6.12 release branch.