Hacker News Reader

Comment by ironhaven | Hacker News Reader

If anybody wants to see an intended use of javascript in SVG images take a look at flamegraph profiles[1]. Very useful to find program hotspots when you can click to focus on particular code paths.

[1] https://brendangregg.com/FlameGraphs/cpu-bash-flamegraph.svg

View on HN

Still not clear why the javascript needs to live inside the SVG. In my mind, the SVG would have declarative metadata and some external javascript would attach behaviour.

Notably, there's significant restrictions on loading external <script> tags if the original file was loaded through file://. This means that your idea would likely require a static file server or similar.

Not nearly as portable as what we have now.

Agreed, at some point custom “declarative metadata” just becomes a nonstandard onclick handler.

So a single .svg file can actually be a whole app? Wow we reinvented flash.

That's part of the original design goals for it. Scripting support has been part of it from the very beginning, to allow for time-based animation etc.

While scripting could be used for time-based animations, the preference was to use the declarative SMIL. Scripting support was intended to allow more sophisticated interactive graphics.

Hand authoring complex SMIL animations really sucks. The declarative nature introduces obnoxious limitations, and none of the browsers interpret it identically. I’ve spent hours writing it just to find out it only works in chrome, then spend a few more hours hunting down and finding work arounds for all of the bugs in each browser’s rendering engine.

It would have probably taken off if there was a way to have wrapped text in the early days.

SVG was the result of an effort to make an open standard for vector graphics. As is typical for open standards, it wasn't an entirely novel concept. There were several competing alternatives; IIRC, SVG was one of half a dozen proposals submitted, and most of those proposals were evolutions of prior designs/attempts at a standard. While flash was an original design, it was as much a "reinvented Shockwave" as SVG was a "reinvented flash".

Agree. What (legitimate) use case does Javascript inside an SVG address?

That sounds like a workable model for vector graphics in browsers; it's just not describing SVG's design. It very deliberately was meant to contain not just vector model, but also a dynamic/interactive environment.

From the standard: https://www.w3.org/TR/SVG11/intro.html

"Sophisticated applications of SVG are possible by use of a supplemental scripting language which accesses SVG Document Object Model (DOM), which provides complete access to all elements, attributes and properties. A rich set of event handlers such as ‘onmouseover’ and ‘onclick’ can be assigned to any SVG graphical object. Because of its compatibility and leveraging of other Web standards, features like scripting can be done on XHTML and SVG elements simultaneously within the same Web page."

But we're explicitly criticizing SVG's design! SVG doesn't contain horrible things by accident of implementation, it was specified to contain those horrible things.

Defending against this criticism by saying the behavior is in the spec is not relevant.

I think you're missing that it was a design goal to have that support in the spec. Scripting was a requirement, not a design choice.

Then Javascript inside SVG should not have any power over the HTML page it's contained in.

At the time, it's not what people wanted. It was pretty common for Flash apps to have access to the whole page.

I have been told that another intended use of javascript was to size a visual element like a rectangle to be the bounding box of a text string.

Reply on news.ycombinator.com