I have to admit I was a little hesitant at first to get guidance and clarity on a dozen or so items we found to be ambiguous (see public SVG WG discussion threads), however the positive response has been overwhelming. Of course we are not the only members raising these issues, but we are happy to be a part of the process. The future of SVG is bright.

Additionally, Microsoft looks forward to hosting the next SVG Working Group face-to-face meeting in Brussels this May.

A special thanks to those on the Working Group for their warm welcome and shared goals of creating a specification that will promote standards based interoperable graphics for the web.

@John A. Bilicki III – I’ve been to your site and although you keep up with technology in the browser your site is so 1989 looking that it isn’t funny. I’m not sure what work outside your homepage you do but this doesn’t serve you well as a portfolio site. "Welcome to Version 2.8 Preview IV, the twenty eighth version of JAB Creations, the home page" – yeah, no thanks.

Sorry dude.

As for IE. I don’t use it now and unless IE9 does "rock" I doubt anyone will switch back.

You’re reply to my question unfortunately failed to teach me anything new. That IE8 supported this daft xsl stylesheet trick in standards rendering mode is something I knew; it still doesn’t mean that the document is being properly processed as xhtml.

There are many subtle differences between how javascript and css should be treated for xhtml and for html documents and the DOM should be different for both. XML should further allow the use of namespace aware methods.

It is true that this funny application/xml trick causes IE to test for document well-formedness. However, beyond that, it is to be doubted that the document is treated any further as true xhtml by IE. That will have to wait for IE9 (or later).

It is further debatable, to say the least, to say that refusing to render ill-formed xhtml is a clear blessing. For automated xml processing, it should certainly be a boon, as it prevents garbage being processed into sewage, but for the human-oriented www, it is possibly quite disruptive. I think you are wrong indeed to suggest that people might learn more quickly of html faults due to browsers not merely providing a warning, but refusing to render them at all. Have you never heard of html validators?

I don’t want to be rude, but if that website is the pinnacle of your web development, it is rather hard to take you seriously. The aesthetic is terrible, the technical construction perhaps even more so.

A few brief examples:

a) the document doesn’t even validate due to the presence of two id="news" twice;

b) the document renders IE6 into a quivering heap, such as I had to put it out of its misery with the Windows Taskbar;

@Gord If you the lack insight that others have then it’s not my problem but if you’re going to grief keep in mind when it comes to you and I; I’m the one who has in the past and will in the future continue to be able to demonstrate to great length what I am capable of while at the same time nothing came up for "gord" on Bing or Google that I could associate a real person with.

IE9 is going to rock and I for one am glad that it is already creating a clear distinction between those with legitimate concerns such as standards and mere internet trolls.

Without promising, I think the amount of talk about it is a clear enough sign. Considering IE has VML already, and MS Word has MathML already, I think it will be doable to have SVG and MathML ready by the time IE9 ships. Throw in some CSS3 and some GPU based web page acceleration, and I think developers will be happy. Well, not until they kill IE6.

Please improve the very slow developer tools. Or open source at least that part.

It is so nice that Microsoft joined the SVG group, but quite frankly, what took so long? And when will we see SVG support in IE?

Is the "lets release a major version every couple of years" really the best philosophy to develop a browser nowadays? Wouldn’t it be better to have a component based browser where you can ship small updates and new features more frequently without breaking the entire beast?

Great stuff! I’m particular pleased that you’re concentrating on SVG use cases for building graphically rich web apps. Really looking forward to what IE9, and other browsers, deliver in this area. Keep up the good work Patrick!

Every canvas/svg use i’ve ever seen is CPU intensive garbage. Whatever it takes to make that change, do that. Or maybe we just shouldn’t be using them. I don’t want illustrator like functionality gobbling up cycles in my browser. Keep it simple.

@LenardG: From the tea leaves I’ve read, I think the new version of IE will come out with each version of Windows (every three years) with one interim version, putting them at around every 18 months. Just how many version of how many browsers do you want to support, anyhow?

At least with Firefox/Safari/Chrome you can demand the newest version of each from your users since those users likely went and installed it. But with Chrome getting bundled on machines, etc., that assumption/requirement may have to get changed.

That said, I agree that it should be faster while IE is so far behind and is in catchup mode. Faster would be better here. Two releases between Win7 and Win8 would be in order.

@hAl: Thank you for the reference to OMML. My only experience with MathML is making Firebug work with it in Firebug 1.5.

@gabe: Yes and no… it really depends on what happens to be ready and when. If, for example, the GPU and JIT work was ready now, but the SVG and other stuff aren’t, then testing might be improved by not having to test too many changes all at once. Moot point however, as I don’t see once a year happening, though they have done it before…

History:

1995 – IE 1, IE 2

1996 – IE 3

1997 – IE 4

1998 – IE 4.5

1999 – IE 5

2000 – IE 5.5

2001 – IE 6

2002

2003

2004

2005

2006 – IE 7

2007

2008

2009 – IE 8

Kudus not just to MS for engaging the SVG community, but to the SVG community for engaging MS in meaningful ways (rather than just a lot of rants like on the comments of this blog).

If they are discussing ambiguous items in the specs, it probably means that they have started working on an implementation. (Remember the start of the work on CSS 2.1 for IE 8? They were discussing ambiguous items and churning out test cases.)

On the other hand, this is pure speculation, there is no mention of plans for SVG support in IE. This probably means that the work is not done yet, so they are not allowed to discuss it publicly. (The "under-promise and over-deliver" motto.)

@Steven Roussey: I have been working with and developing enterprise application and I do know that for many enterprises there are policies in place that prevent browser updates. They are too afraid to upgrade, because all the web applications would need to be tested and checked so nothing breaks. Many also rely on IE.

But I don’t think this should be something to block the development and release of new versions, especially because – as you also pointed out – IE needs to catch up with other browsers. The Chrome update model suits me – it just updates itself when there is something new. I do realize that might not suit everybody, of course 🙂 But it might have prevented such things as IE6 still being majorly present. Just ask our Web Designers opinion of that 🙂

While I also understand the reasons behind connecting IE versions with OS releases I still think it badly affects new features not getting out fast enough to the existing user base.

@John Sausage: Well with Vista came IE7, and after IE6, it was about time to give something new to IE! No wonder it was popular when it added some features to IE that were greatly missed. But adding useful and good features one at a time could also be greeted with excitement.

I’m also pleased to see evidence from the IE team regarding will to involve in the SVG community (joining the SVG WG and increasing activity in its mailing list being clear proof). 🙂

I agree with Steve [1] that its not only the IE team but also the community which must be involved in the process; the initial feedback seems nice, and I hope to see further progress on both. 😉

Disclosing a schedule on the availability of an SVG implementation within the IE roadmap would be great, but not a requisite (i.e., if Microsoft/IE team wants to make a surprise to the world, that’s fine also!). I just recall the past in obscuring this sort of information, giving the impression that standards compliance is being stalled, reason why I’m highlighting this roadmap thing (but I’m convinced you already are aware of that, in the scope of CSS2/3). 😉

So far a lot of things I’m hoping to see in IE9 have been confirmed. Honestly as much as I can’t wait to try it out I think if it really only took three weeks of work to add GPU acceleration and CSS3 selectors that I’d rather wait for the RTM by an extra month or two if IE9 does not become the Netscape 4 at the end of this decade.

I’m pretty sure we might see application/xhtml+xml support in IE9 and after getting application/xml to work in IE8 in standards mode and honestly I do prefer the full page break that IE, Opera, and Gecko execute instead of the half-rendering in WebKit (as much as I do like WebKit for other reasons).

I’d also really like to see CSS3 multi-column support make it in to IE9. Really, it makes reading pages across my 24 inch screen much nicer. Don’t get me wrong, CSS3 selectors are great but it’s CSS3 properties that will make or break browsers in ten years.

Shadows and transitions are another things that are pretty much a must-have. Honestly while I think jQuery is nice it’s NOT a replacement for JavaScript. In fact I would go so far as to say if IE9 RTM is covers all the bases that we really need that JavaScript frameworks (not just jQuery) in general will become the next Netscape 4. There are still an absurd number of people surfing with dial-up and frankly I’m really getting irked by the rise of sites that automatically resolve JavaScript issues with jQuery instead of JavaScript directly and then the people asking the questions presuming it’s somehow acceptable to not learn JavaScript and to just accept jQuery or any other framework as somehow an acceptable "replacement" for JavaScript. I’d like to see the web free of JavaScript frameworks by the end of this decade and I think Microsoft could really help the web in this regard should you folks cover all the right bases. I’m not trying to be disrespectful to the folks who work on frameworks (they’re geniuses for making things just work as well as they do) however they primarily exist to enable older browsers to do things supported by very little code in newer specs (e.g. * {-o-transition-property: background-color, background-image, border, color, opacity; -o-transition-duration: 0.8s;}). So again I’ll reiterate my most important point: it’s perfectly fine in my opinion to spend those extra few weeks to get those extra things in to IE9 if it means that we won’t be cursing IE9 at the end of the decade.

Going back to the blog topic while I don’t work with SVG I’m happy to see it finally getting the support it deserves. I think it’s awesome you guys are working with others in the standards community and look forward to seeing Microsoft bringing it’s own contribution of innovation (e.g. AJAX, favicons, etc) while simultaneously embracing standards. This decade is going to seriously rock for everyone. 🙂

However the problem is that it only works in IE and it is a legacy technology.

Web Technology these days must not be proprietary and must work in all browsers.

HTML5, SVG, Canvas, etc. are all open technologies with specs that can be adhered to.

If I build (and I have) an application that uses SVG or Canvas it works across multiple browsers… Firefox, Chrome, Safari, & Opera.

Only IE is behind with these technologies and it is hurting IE as a development platform.

Today (2010) if I was asked to build an application in VML or VBScript or make use of ActiveX calls or proprietary JScript, or only work in IE I would refuse point blank.

More importantly the best development and debugging tools are only available for Chrome, Firefox etc. I would hate to have to use inferior development/debug tools to build my application when there are so many better tools available.

Luckily IE6 is on the way out. Existing apps support it, but new ones will not. The faster IE can catch up to modern browsers like Firefox and Chrome, the faster the Web and all Web related technologies can flourish.

@John A Bliecki III>>>I’m pretty sure we might see application/xhtml+xml support in IE9 and after getting application/xml to work in IE8 in standards mode and honestly>>>

Have I missed something… application/xml and IE8…?

I know the old declare an xsl stylesheet trick as text/xsl was discovered about 2003 (it’s documented, for instance, at http://www.w3.org/MarkUp/2004/xhtml-faq#ie) and was shown to work at the time with IE 5, IE 5.5 and IE 6. It even works when the xsl-stylesheet is declared in the html as application/xml, but to my knowledge it doesn’t work if the MIME type for the xsl stylesheet is set to application/xml (set using AddType in an appropriate .htaccess or in the httpd.conf).

It is true that IE checks for well-formedness errors, but it then proceeds to handle the served document further as html (there are dozens of ways that this is visible).

I’m not sure what use this particular trick is at all, and it certainly doesn’t allow xhtml to be served to IE with its correct application/xhtml+xml MIME type. It almost seems, to be brutally honest, as a sort of sick joke.

However, you mention IE8 specifically, so perhaps there has been some development that I am not aware of, in which case I would be very happy to hear more…

@Paul, IE has supported XML since 5.0; what I was talking about was application/xml support with ***standards mode enabled***. The IE team unlocked standards mode for pages served as application/xml in IE 8.0. So even if you can’t directly served XHTML 1.1 correctly it’s "okay" to serve is as application/xml.

The main benefit of XHTML and using either application/xml or ideally application/xhtml+xml is if there is an XML error on the page the entire page will break. Some people might think that is about as undesirable as it gets and they couldn’t be any more wrong. In just one of many examples I remember a thread about a guy who checked everything from PHP, his database, everything because his page worked fine in everything except Safari; hours later he discovered he was missing a quote. Had he served his page as XHTML he would have known the issue and had it fixed literally in seconds, not hours. So XHTML is a *MAJOR* must-have just for that one benefit.

Unfortunately IE does request the doctype URL located on the W3C’s website and add to the fact bots have been mindlessly wasting their bandwidth which all but prevented pages from being served as application/xml in IE 8 in standards mode (and in quirks mode only in older versions). However ironically HTML5’s not-a-doctype doctype (I personally feel the doctype should retain the version number for forward compatibility) will work and IE will *not* make, depend, and thus fail to render the page.

There is a second thing necessary to making IE8 render a page as XML, include the following line (Dean Edwards gets the credit for this) after your XML declaration…

However when serving a page as UTF-8 if you need non-Latin characters to display correctly you need to use the following meta element in IE7 or older (I think though I’m a few days from finishing work on IE specific issues on my "nightly builds" so-to-speak)…

@Steven Roussey – quite true, HTML5 and Canvas are still in draft mode… but that didn’t stop browsers working on supporting them. Sure some of the details need to be worked out… but a "date" element as implemented by Opera is pretty much on par with what was expected.

Ditto for the Canvas stuff that works just fine in Firefox,Safari,Chrome and Opera… since they all followed the "draft" specs.

I’m not to worried about whether the specs are in draft, or finalized… its the commitment to implement them within a reasonable timeframe that is the issue.

I was developing in SVG 8 years ago… have bought printed books on how to do it… but support in IE just isn’t there.

There are times when I feel that IE is not just behind the curve… more that IE isn’t even on the curve yet.

I’d like to see a post that commits to "trying" to support SVG in IE9. So far it has all be very wishy washy non-commitment which doesn’t make me confident in IE/MSFT at all.

@John A. Bilicki III – "IE9 is going to rock".. thats a pretty bold statement seeing that most of us have not seen anything concrete about IE9 other that it is supposed to support CSS rounded corners and reasonable speed JavaScript.

Granted those 2 things are great – but hardly earth shattering since all the other browsers have had both for years.

@John Sausage This decade if you know what you’re doing, maybe the next decade if you don’t…maybe.

@steve You don’t actually think I only read the blog do you?

Different people, different perspectives. Sometimes you will bump in to people who don’t know some things you do and sometimes you’re going to bump in to someone who knows somethings that you don’t. You can visit my site and mess with the functionality…not my latest and greatest (2.9 in March, only a lucky few can see my nightlies) but I bring a lot to the table as far as being able to show I know what I’m talking about. I don’t speak for Microsoft in any way though rest assured the excitement a lot of people will have reasonably soon is the excitement I already have now.

@ IE team… if you had problems with auto updates in the past then that is probably an OS thing too?…

My Mac updates it self no problem and I have had both mac and windows for over 10 years…

Or when my mac updates or prompts me to update it is not super annoying like other…. for some reason mircosoft, firefox, and adobe update / security prompts / alerts… I find EXTREMELY annoying and aggravating… The mac on prompts don’t bother me at all and I actually like them…

Maybe you should do lots of usability and design research on an IE auto updater…

@Steve: IE will never update itself. There’s Windowsupdate and it works for all programs by MS. The only thing missing there is the lack of updates for other software. But I agree that there is a need for updates and that there should be a security warning if you haven’t updated your browser and your av-prog.

Since the CONNECT DB is still actively taking in FR – Feature Requests and PR – Problem Reports on IE8 and IE9 (as discussed here on the IE Blog and in the Connect updates) and the issue I linked to was opened JANUARY 25, 2010 (e.g. for consideration in the IE9 development cycle)

Lets face it, anything that isn’t a high-level security bug report (against IE8) in Connect is automatically pushed to be a bug/feature request against IE9. (If it isn’t, that’s a MAJOR flaw with Connect… but I digress)

Since the original bug: 527016 was closed as postponed in the last week or so, one can only assume that that is the "freshest" info on the matter.

It isn’t like the existing bug: 445283 (posted 5/8/2009) is getting any attention.

All that aside. If you’ve announced IE9 development is under way – why isn’t Connect opened up for IE9 bug/feature submission?

I must confess – I absolutely hate the way IE bug/feature submission is handled through Connect. Totally the wrong tool, totally un-community friendly, totally opaque, totally un-helpful, totally not improving.

What happened to all the comments about this whole public bug tracking thing getting fixed?

At this point I’m completely un-motivated to submit any bugs for IE9 if this process isn’t fixed up.

Sorry I tried to resist ranting but I’m fed up with the lack of transparency and progress with interfacing with the development community.

Steve_web: Its not so much connect is the right tool. It is pretty flexible and each team gets lots of options. Its how each team uses connect.

I think that fact that since the final realse of IE 8 the team rarely posts in the comments or closes bugs untill a year later.

Are you really telling me none of these bugs could be fixed to qualify for inclusion in a IE cumulative update?

Also in that year they cant comment on what they are planning, Seems like they are only open when they want to be, the IE team needs to pick up the pace and start talking more in between releases. about what is coming, and about what bugs can qualify for fixes in bimonthly cumulative updates.

@Cartelett – One of the big issues with VML is that although it was an open standard (according to wikipedia) and based on XML – it suffered from all the issues that IE suffered from with interacting with it.

e.g. you couldn’t use .setAttribute() on elements if the attributes fell in to the pit of attributes that IE chokes on. e.g. ‘style’

or you would need to use CaMeL cAsE because the original IE developers didn’t have the foresight to implement clean APIs.

Then you bundle in the MSO (Microsoft Office) "extensions" to VML and you end up with a non-pure open standard issue.

On the flip side with SVG you have a format that started open and refused to adopt sloppy non-standard intrusions.

It was (and enforced valid XML) and worked with the standard open ECMAScript DOM API.

I haven’t built much with VML… other than to fix IE6/IE7 bugs with PNG Alpha and rounded corners so my perspective on how easy it is slanted – but developing in SVG is simple (as it is with Canvas)

Also keep in mind that development of the VML format ceased in 1998… thus it is a dead technology.

SVG on the other hand is active, it actually is a W3C recommendation (for 7 years now) and has a community of developers actively pushing its adoption and growth.

We’re just waiting for IE to finally jump on board and support the format that every other browser supports so that we can develop for the open web.

The sad news is that even if IE9 comes with native SVG support there will still be users with IE6,IE7, & IE8 for years to come holding the technology back.

It all rolls back to the fact that IE holds back the web by not getting on board with standards early and attempting to implement various proprietary extensions and features that we don’t want.

In this day and age if it isn’t a W3C recommendation (or well on the way to becoming one) developers don’t want it. The only way to succeed in web development these days is to stick with standards… anything else is career suicide.

"The only way to succeed in web development these days is to stick with standards… anything else is career suicide."

On the contrary, the only way to succeed is to deliver what the customer wants, and as developers usually observe, that typically includes support for IE6 and not "standards for standards sake". Customers want interoperability, which isn’t the same thing as standards.

Say what you want @Observer but when my clients suggest they want IE6 support we kindly inform them that an 8 year old browser is out of date and doesn’t provide the rich experience our software was designed to offer. We support IE7 and up or any of the better browsers.

We haven’t lost a customer yet – and most are quite happy when they get a better browser (IE8, Firefox or Chrome typically) and thank us for pushing them/their IT dept. to upgrade.

I did my last webapp code checkin for an IE6 bug in March 2009 and on March 31st we dropped support for IE6.

Btw, the issue with Connect is that each product version (say IE9) is considered as a separate product.

That is they make IE9, and treat IE8 as another produt. This isn’t the case with Mozilla and other non-MS products, they have a steady progress and feature/bug tracking throughout the years, not throught a release and support cycle.

I really hope MS changes this for flagship products like Internet Explorer and Media Players. Another reason for this treatment is they’re linked to respective Windows releases which just makes it harder for all (why bother to pursuade MS to fix something in WMP if you may need to wait for the next Windows to see this fixed?)

MS is now copying bug reports to an internal DB, should use Connect instead in my opinion and keep the feedback loop open for every product (e.g. there’s no way now one can send feedback via Connect for say PowerPoint 2007)