"Rather than embracing SVG as an alternative, Microsoft pursued a blatant copy of Flash in their too-late-to-the-table Silverlight effort."
The author seems to have missed, apart from an initial mention, VML out completely. VML was Microsoft's SVG alternative in IE 5 through 8, not Sliverlight. Sliverlight was a Flash alternative.
VML, although badly documented, can/could do much of what SVG can do, in a few cases it does it better. It was also pretty complete with IE 6 in 2001. SVG had the first very basic version in Firefox 1.5 at the end of 2005, and needed Firefox 3.0 in 2008 before you could say it was reasonably complete. MS thought they had a head-start and could win the vector battle.
The key thing, as well, with VML is that it was built into IE natively. Getting Adobe SVG or Sliverlight added onto IE into large corporate environments was near on impossible. We, fortunately, decided we didn't trust Adobe prior to them killing the IE SVG plugin and were running fully on VML at that point.
The last 10 years of my working life have been based around SVG and VML, my co-founder and I would tell you a similar story. Especially, regarding word-wrap in SVG, it's our top pain point as well. It forced us to use HTML as foreign objects in SVG to get word wrap. Of course, IE never supported FOs, Edge has only just added it.
Silverlight was probably the last major Microsoft attempt at platform lock-in, but it was too late; arguably it was killed by Apple's platform lock-in barrier on iOS just as much as Flash was.
He mentions VML almost right out of the gate, here didn't he? "I have followed the standards for XML-based vector graphics closely. PGML (mainly from Adobe) and VML (mainly from Microsoft),"
Thanks. Yeah I didn't really see VML as relevant after its very inception. True it was sitting there in IE for an extra decade or two but it never had some sort of resurgence or potential that I saw. Silverlight on the other hand had serious people saying "this is the future!" When VML first came out, it had to be taken seriously. Next to PGML, not so much.
since no one's done it yet, i'll mention Raphaël [1] that has served for a long time to provide a single interface to SVG w/VML fallback back to ie6. (supporting only svg features that can be supported/mimicked in vml)
But it is now end of life. The people behind it went on to Snap.svg[1]. Raphaël was great for VML fallback but now that is no longer needed. It is interesting to see just how many people Adobe has hired that worked on SVG (and projects around it like Raphaël). When I was at Teespring, we used Raphaël and some plugins in the web-based design editor before we wrote our own equivalent (without VML support).
The huge pain point in SVG is fonts. Native SVG fonts died. Trying to do exact pixel-perfect layout in SVG for text is now very difficult. See trying to measure the width of a string in a given font.
by "people" you mean Dmitry, who was hired by Adobe and subsequently wrote Snap.svg (perhaps with others, though he seems to be the primary maintainer of both libs)
I didn't name names because I didn't recall who did what. But when we were looking for people with SVG experience, I went down the contributor list to both projects and something like the top 10 were all now at Adobe. This is my recollection from over a year ago so I may have some details slightly wrong.
I think the more interesting aspect is that Adobe hires so many developers with vector graphics experience that it is harder to find them in the SF Bay Area (from the talent pool who is interested/willing to work at a startup). Obviously, this is conjecture.
But definitely a huge thanks to Dmitry for his work and for sharing it.
I was involved early with SVG. I was the Javascript test engineer at Adobe for their plugin, and I sat in on some of the working group meetings. When I left I found the marketing department had been raiding my tests for marketing content, so I contracted back to them and built a couple cool demos for adobe.com/svg.
Years later I was interviewing and my interviewer asked me a lot of questions about one example in particular. It turns out he had run across an example and it was exactly what they wanted for their project, but they didn't understand the math. He had tried to find me with no luck, going so far as to call Adobe and find my coordinator who refused to give out my name.
I opened the sample for him (it was still up), clicked on View Source and pointed to the first line that said "Author: [My fairly unique name]". His response was "DAMN IT! It was that easy?!?!?!"
He forgot about Microsoft's first attempt at making a Flash/vector competitor, Liquid Motion[1]. It was out around the same time Flash 3/4 started taking off. They later tried again with Silverlight which was a nice effort but horrible timing with mobile about to kill plugins just a couple years later.
Liquid Motion seemed like it could do some damage as DHTML was huge from IE 3/4 and it had the developers on their side because Netscape was wallowing and sucked (document.layers), but they just dropped it. They also did that with tablets and phones so Microsoft usually needs a successful example they can innovate on it seems, otherwise they fumble a bit.
I had the bad judgement to build my VR app on top of Liquid Motion.
Then Microsoft bought Dimension-X (acquihire) and tubed the product, leaving me an orphan. Liquid Motion greatly boosted the mindshare for Java. An OpenGL code base written in Java validated both technologies. So of course it had to die.
For Sun's part, they went the full quixotic with Java 3D, for years refusing to acknowledge anyone would want to use just OpenGL as is. But for its time, Java 3D was the J2EE of scene graph libraries [ducks].
Source: I helped former Liquid Motion employee "Alligator Descartes" design and implement the first public Java OpenGL bindings called "Magician", which was copied by JOGL and others.
I found a discussion of Microsoft on 2004, why they copied all SVG elements and capitalized them: "SVG has its own set of conventions for element and attribute names that is at odds with the existing .NET Framework class library." https://msdn.microsoft.com/en-us/library/aa480164.aspx#avalo...
A frequently asked question is: Why doesn't Avalon just use SVG? On the face of it, it seems strange to invent a new way of representing vector graphics in markup when a standard already exists. However, the principal advantage of these shape classes is that they have been designed to integrate into the Avalon programming model. The vector drawing elements derive from the same FrameworkElement base class as all other XAML elements, and follow the same naming conventions. SVG has its own set of conventions for element and attribute names that is at odds with the existing .NET Framework class library. Furthermore, SVG elements were not designed to fit into the Avalon object model. By not using SVG, Avalon ensures that vector graphics can be mixed in with any other kind of markup in your XAML, and can take advantage of all of the same layout facilities. (Note that in the version of the Longhorn SDK documentation released at the 2003 PDC, the XAML elements used for vector drawing are sometimes referred to collectively as WVG (Windows Vector Graphics). However, Microsoft is no longer using this name, because it implies, incorrectly, that these elements are somehow distinct from all of the other elements supported by Avalon.)
Which is a lot more than just "SVG has its own set of conventions for element and attribute names that is at odds with the existing .NET Framework class library.".
I had some visual analytics tools that ran "canvas" on IE6 in 2008 thanks to VML. Never did pure VML but it was a nice crutch to have if you wanted to get very experimental and very cross-browser.
Not to mention performance (or lack thereof). Adobe SVG on a PIII/P4 was like running Photoshop on a 486SX; a small-radius Gaussian blur, like for a drop shadow, would peg the CPU for several minutes even on a simple shape.
IE SVG render support was very fast, thanks to their expertise with the older VML format. Chrome, Safari and Firefox were slower in SVG rendering (thousands of nodes), but had faster Canvas rendering.
Animations have also been a pain point for me - part of the problem being the lack of SMIL support in some browsers as well as differing behavior and support with regards to CSS animations.
The author seems to have missed, apart from an initial mention, VML out completely. VML was Microsoft's SVG alternative in IE 5 through 8, not Sliverlight. Sliverlight was a Flash alternative.
VML, although badly documented, can/could do much of what SVG can do, in a few cases it does it better. It was also pretty complete with IE 6 in 2001. SVG had the first very basic version in Firefox 1.5 at the end of 2005, and needed Firefox 3.0 in 2008 before you could say it was reasonably complete. MS thought they had a head-start and could win the vector battle.
The key thing, as well, with VML is that it was built into IE natively. Getting Adobe SVG or Sliverlight added onto IE into large corporate environments was near on impossible. We, fortunately, decided we didn't trust Adobe prior to them killing the IE SVG plugin and were running fully on VML at that point.
The last 10 years of my working life have been based around SVG and VML, my co-founder and I would tell you a similar story. Especially, regarding word-wrap in SVG, it's our top pain point as well. It forced us to use HTML as foreign objects in SVG to get word wrap. Of course, IE never supported FOs, Edge has only just added it.