If you think C++ or PDF specs are bloated, wait until you find about the old W3C Drafts for SVG…
Nowadays, when you talk about SVG, it’s mostly assumed that you’re talking about static vector graphics images for embedding in the webpages or apps (logos, icons, illustrations). Occasionally, SVGs are animated – and that would be called an “advanced” use of the format.
So why would raw network sockets ever got considered for SVG?
Well, back in 2001, W3C introduced the first SVG specification. It was mostly about displaying vector graphics that could be made interactive via scripting, pretty much what you think of SVG these days. In 2003, however, they added two new “profiles”: SVG Tiny and SVG Basic, aimed at mobile devices. SVG Tiny was a very restricted subset of SVG “Full” and SVG Basic was a middle-ground, aimed at the smartphones of that time (PDAs). SVG Basic also supported some scripting, although not to the full extent of SVG Full.
And from here you can see where we are heading into: a W3C spec that supports vectors, animations, rich media and
scripting, and that’s getting first-class support for mobile devices. What (besides the common sense) prevents us from
developing a full application in a
.svg file in the future? That’s it: networking support.
So, in 2004, a new working draft on SVG 1.2 Full was presented and that was the time when SVG got (a draft of) networking support for the “Full” spec (aimed at desktops).
But it’s 2004, things are not that standardized yet and just HTTP support is not enough. So there was also raw socket support for SVG, so our computers (maybe PDAs too, in the future?) will be able to finally talk to any proprietary protocol or non-HTTP endpoint and, why not, even introduce their own communication protocols, because the world surely needs more of them.
But at least it will be secure to use. Right? Riiiight?
Well, although the draft warned about security implications of the proposed networking stack for SVGs, it never intended to address those issues, instead saying web browsers should provide the security, without going into much detail. Given that 2004 got known as the “Internet Explorer Year of Shame”, after successive remote code executions flaws were discovered in the Microsoft’s browser, it’s not a surprise that the proposal went nowhere.
I’m still pissed I can’t use Inkscape as my IDE.
Notice: this was my first time searching through historical W3C documents. If I missed something or just got something wrong, feel free to write me, and I’ll happily update this article.