Update (and quite a long one): As per Jeff Schiller’s and Len’s comments below (thanks Jeff, Len!)

* Fixed the mention of CLI to read CLR instead. The difference to those of you unaware… CLI refers to the ECMA Common Language Infrastructure specification, the CLR is the runtime implementation of the CLI spec, whether this be Microsoft, Novell/Ximian/Mono, or DotGNU Portable.NET. Also, see footnote one below.
* As both Jeff and Len point out, the difference between a plugin solution and Trident (IE’s rendering engine)-native support for SVG is of major significance. If you consider things from a very simplistic perspective, a plugin sits on top of the underlying processing engine, so at a bare minimum, when Trident notices there is an SVG document to render, the cost of passing this document to the plugin for rendering, wait for the result, to then output the result is substantial. The result in this case is a simple performance issue.

Of course taking things one step further, compound documents in which could contain any number of formats such as XHTML, raw XML, reference to CSS files (or embedded CSS for that matter), in the case of Mozilla, XUL and XForms, in the case of Opera, WebForms 2.0, and in Mozilla, Opera, and (as Jeff points out, eventually) Safari, SVG and Canvas, And this is a non-inclusive list, especially when you consider microformats (see Uche’s recent article that covers this topic extremely well!) in which can be extended without limits given the now ALL major/significant-browser support for XSLT. Even excluding microformats, and ignoring the current set of standards groups at the W3C that are working towards standardizing a much richer set of UI components, as well as a detailed compound document specication — Even then you still have a large base of important standards in which need pure native support to be enabled to truly take advantage of all that compound documents have to offer this WorldWideWeb of ours.

With that said — I really need to clarify my point regarding the use of Adobe’s SVG engine. This is a pure-and-simple time to market type solution, and should be seen as only temporary such that enough time can be allowed for MS to build solid native SVG support directly into the Trident engine. This is REALLY important stuff! (both the “do what you have to do to get SVG support integrated into IE7″, even if that means via an existing plugin as well as the “then take the time to do it right such that in future releases the support is native, and the conversion to XAML and back again, completely transparent.

Of course as Len helps clarify (once again, thanks Len!),

Given thst SVG is a two dimensional vector graphics language for the web (no online 3D gaming worlds with SVG — but to me this is a good thing as it allows SVG to remain simple and easy to implement from a web development and well as a rendering engine development perspective) and furthermore, is nothing more than than a two dimensional vector graphics language for the web, there is no one-to-one mapping of SVG to XAML. The reason: XAML, by definition, is a way to wire together applications that defines an applications GUI framework, how to handle the various events that take place (read: what code should handle an onclick event, etc…), and allows for embedding of code, or code behind, etc… etc… etc… In other words, XAML is what you basically get with a combination of CSS, SVG, and XUL, but given the maturity of the MS-COM roots in which this extends from means that XAML is a much more suitable solution when your dealing with the development of bullet-proof desktop applications.

But thats the point… SVG was specifically designed for the web, and as such, builds from existing web standards, and does so with a lightweight, easy to understand, yet EXTREMELY powerful XML-based language syntax that flat out kicks-a$$!

With this in mind, it makes sense to have a two native vector graphics solutions as a part of the Windows/IE platform combination. With SVG being passed around as raw XML in much the same way exactly the same way as HTML/XHTML is today, keeping things lightweight, or in other words, not bound to an extensive array of COM-influenced components in which would create a mess of nastiness not unlike exactly like what we had with ActiveX Hell (in regards to the gaping wide security holes, not the underlying COM foundation itself… I’m a BIG fan of COM, so I don’t want to come across as downplaying COM-influenced architectures… just the implementations of COM that allow for extensive exploitation of systems by hackers… in other words, passing randomly compiled COM-components via a Web browser interface, and giving these components raw access to the underlying system — bad idea. Building COM-influenced desktop application architectures in which the components being passed around are done so in a much more controlled, secured manner with checkpoints along the way to ensure the human factor (e.g. Click here for a (sur)prize!) isn’t a factor — GREAT IDEA!!!

Anyone want to take this from here and make it look/sound a bit prettier? If yes, would love to create a brand new post with nothing but a simple and precise reasoning as to why SVG on the web via web browsers makes perfect sense, and as such MS should not only consider native support, but be given complete and straight forward justification that this makes true business sense, and in no way undermines what they have done/are doing in the XAML world.

If you think you can do just such a thing, and do so in, say, 100 words or less… please leave this as a comment, and then the community can vote (via a comment) as to which one they think is the best explanation/business justification for implementing SVG in the long term (as well as whatever way they can get it into the final release of IE7, including via a temporary plugin solution if there is simply no time to develop their own solution in time (and I have my doubts that would even be possible. While theres a TON of talent in Redmond, believe it or not, resources are actually limited, as this is not the only problem they need to address in the grand scheme of IE7 things… as such, please keep this in mind if you decide to take on the 100 words or less challenge…

Anyone up for the task?

The winner will get their own post (clarification: I will need to make the post, but do do so as a proxy… I don’t have the power to give you your own blog on O’Reilly unfortunately), with full credit for coming up with what the community believes to be the best business justification for MS to implement SVG support in IE7 via a plugin solution if necessary, and native SVG support as soon as they possibly can.

I might even be able to convince the folks at O’Reilly to thrown in a free book or something (don’t want to make any promises, but I have my doubts I’m getting myself in TOO much trouble by suggesting this as a possibility ;) so if for no other reason, I guess theres that. :)

The comment section is standing by :)

[orig. post]
Yes please!

Request SVG Support in Internet Explorer 7

There is a current “enhancement bug” filed at Microsoft’s IE7 development site. Show your support for SVG by voting for this bug! Many people are clamoring for native SVG support in IE. A workaround has also been suggested as a stopgap measure, which is the bundling of an SVG viewer (such as the Adobe one) with IE7. If you don’t have a Microsoft Passport, you will need to register for one, and join the “Internet Explorer Feedback” program (under “Available Programs”). Then, just search for “SVG” under the “Feedback” tab.

The link provided in this post results in an error page if you are not already signed into the Microsoft Connect site (using an MS Passport if you have one) and furthermore already signed up for the “Internet Explorer Feedback” program. If this is the case (and my guess is that for a lot of you, it is) then I would instead start at the front page of the Microsoft Connect site, sign in (or up and then in) with your Passport, and select “Available Programs”, scroll down to ‘Internet Explorer Feedback’ and click ‘Apply’ in the far right column of this row. Access to the program is then immediatte.

Once this has taken place, if its not obvious right away where to place your vote, access the feedback area, look to the right hand side and locate the ‘Top Rated’ column, if its not yet in the Top Rated listing (my goal is to get it to the Top Rated list, which at present time it is not… its a new request from what I can tell, and as such, the reason its not at the top yet (assuming, of course, that if the opportunity is there, people will be voting for this feature like mad)) click the “More” link at the bottom (the previous “More” link should take you their as well, but just in case I want to provide the full list of instructions.), scroll down the page to about mid-way and keep an eye out for the title “Add support for SVG graphics” (again, if you are already logged in and have applied for the program, this link *SHOULD* take you directly to it… but for the same reasons as the last comment, it seems appropriate to provide the full list of instructions.)

For the record, here is a copy of my own feelings as to how they should go about this, and why:

Three things:

* Provide SVG support natively via a bundling agreement with Adobe.
* Let SVG handle the browser-based world of vector graphics — it’s lightweight, complimented by existing CSS standards/support for these standards, with existing and extensive support for mobile devices.
* Build a bridge to XAML that allows a simple way to take the same SVG, convert it to XAML, and then extend the result into a desktop application. This is an easy transformation file which could be invoked from directly with “Sparkle.”

The result is better support for web standards, more people will take IE7 seriously, develop web applications using SVG, and with a simple bridge, will extend these applications to the desktop where they will have the power and strength of using XAML to wire-up their desktop applications directly into the CLI CLR without even thinking twice.

Gain the support of the SVG community, and my guess is you will find VERY FEW naysayers left who can feel justified in any sort of suggestion that MS doesn’t care about web standards.

—
[1] - NOTE: Does anyone know/have feelings towards whether Rotor should be included in the list of working runtime implementations of the CLI specification. (side-note: In quickly searching for the correct link to Rotor, I noticed for the first time the .tgz extension to the download… not that this means anything all that much, just never seen anything but a zip file in the download center before, and given the fact there is no MS-built native support for tar or gz compression, it seems interesting to note its usage.)