Supporting Web Standards Development with SuperPreview

This post is a guest post from Steve Guttman, of the Expression Web team. Expression Web has created an interesting tool, SuperPreview, which we thought the IE blog audience would be interested in.

Internet Explorer 8 is an important release because it reconfirms Microsoft’s commitment to interoperability and renewed emphasis on Web Standards. My team—which develops the authoring tool, Expression Web—is also pretty emphatic about Web Standards. We’re in the process of doing significant tooling (and retooling) so we can support existing and emerging specifications, reliably.

The Expression Web team recently shipped SuperPreview for Internet Explorer, a FREE tool for performing cross-browser debugging across Internet Explorer, including versions 6, 7, and 8. This tool also helps developers and site owners in migrating their sites from earlier versions of Internet Explorer to the standards-compliant Internet Explorer 8. This is a subset of the full version of SuperPreview (which also supports Firefox) and which ships with Expression Web 3. You can download it here. You can learn more about SuperPreview for Internet Explorer on the Expression Web team blog.

@John – I didn’t swear. The comment above mine had a swear word (noob sh**te browser I think), but I don’t do that sort of thing.

My comment was probably highly sarcastic but I didn’t swear or break the rules.

The IE team _do not_ need constructive criticism, they know exactly what is going on and yet they still ignore developers, developers, developers, developers, this only really leaves us with this blog to vent our frustrations and demand an apology from Mr Ballmer.

Translation: Microsoft has actively sought to subvert standards and interoperability for many years. Because we have caused so many problems and because we continue to hold back progress (CSS 3?) have this tool so that you can write hacky, difficult to maintain code to make things work in the lowest common denominator.

IEtester doesn’t provide tools to do ‘pixel perfect’ alignments (which should NOT be a goal, since not all browsers provide the same basic styles for HTML elements, and providing a complete CSS stylesheet every time is something that almost no one ever does).

IEtester can run with (almost) whatever version of IE you have installed; you don’t need to have IE 8 installed to have access to IE 5.5 and IE 7, and those that are there are the ‘real’ thing (Quirks mode in IE 6+ is not exactly like IE 5.5, IE 8’s compatibility mode isn’t exactly like IE 7).

Now if you’ll excuse me, I gotta go and find what hack I wrote in my CSS is twisting KHTML/Webkit’s panties in a knot – because ExpressionWeb might take Gecko into account, but the other FOSS engine isn’t.

Opera? What’s that?

(note to those mocking so-called ‘standards’ engines: they pretty much deal with correct input the same way, it’s hacks that are not treated the same – that’s why they are hacks).

Note: Super Preview is only as useful as getting a screenshot of a web page in a different browser. It won’t really help you "debug" problems.

You can’t click links, view animations, submit forms, or anything that may help you solve a problem. If you’re doing serious work you’re better off downloading the IE VPC images from Microsoft instead.

The pay version only supports Firefox? Wasn’t the intent to include support for Safari and Opera? Or is that not possible due to licensing (I’m sure Webkit could be included, but I don’t know about V8 or SquirrelFish).

And without a CSS editor (or even a viewer, though the documentation seems to indicate there is) or the ability to interact with the page this isn’t that helpful. Is this feature available with the pay version?

I think one of the largest obstacles to web standards is static coding practices in general. It starts with that parent most div…and simply cascades to the deepest nested elements. It makes changing code a nightmare. Using dynamic code (even if the parent most div has that corporate set width) things simply work.

I do all my coding in a text editor so I’m not familiar with Expression Web however your team could ease a lot of headaches by shifting designer’s attention (and developers outsourced to do web design) from static values on certain things (such as divisible elements) and provide short tutorials, perhaps videos, of the massive amounts of benefits (and saved time) by using dynamic values.

IETester will allow you to interact with your pages and thus test the HTML, the CSS, the JavaScript and the rendering at any stage.

I also agree that pixel perfect isn’t the goal and you will suffer trying to get it.

The only beef I have with IETester (which I otherwise highly recommend) is that I’ve had issues with it trying to launch and interact with popups. Other than that it is an amazing tool that MS would be wise to endorse.

@Steve: As you noted, IETester has known problems owing to the fact that it’s cobbling together bits of various browser versions to attempt to support an unsupported scenario. One place you’ll see problems, as you’ve found, is cases where there’s an interaction between the frame and the HTML, as in the popup case.

Obviously, if it’s working well for your needs, I’m happy to hear it, but to get reliable results, my recommendation remains use of VirtualPC in the general case, and SuperPreview for layout-related comparisons.

Dealing with a static image of a site in IE is of pretty limited value to me. My normal IE bug squashing process uses the IE Web Developer toolbar (slogan: Like firebug but, you know, just awful and microsofty). If there is a rendering problem I select an element and throw the insane ‘zoom: 1’ rule at it to trigger ‘layout’ (go Microsoft) and go from there.

I’m serious. Editing the stylesheet and reloading the page just takes too long as you have to back out your change if it didn’t work.

The first thing Microsoft should do is just admit the horrible things they have done and apologise, over and over again, then get out of the browser market for good. They just can’t keep up. Their release cycle is too slow and they are linked to OS releases.

The second is to educate people to use their inferior Web developer toolbar to deal with the bugs that they’ve kindly given us (while telling us how great IE is).

I do wonder whether Microsoftys actually believe the nonsense spin they put on this stuff. I don’t think they have any idea. I’d love to sit with someone from Microsoft for a day and explain to them the number of times IE’s inadequacies (all versions) limits my options forces hacky workarounds. Rounded corners? Drop shadow? Text-shadows? That can be done with CSS. Oh, whoops! IE exists.

The main problem with none IE browsers is that you can not use realy then in a corporate environment. IE is the only browser that can be (out-of-the-box) configured using Group Policies and Group Policy Preferences, updated via WSUS and supports intergrated authentication.

Like it or not, but these are the tools used by many companies. Not supporting them (e.g. Firefox) keeps them out of large scale deployments

Also, who what’s to enter extra login prompts in a Browser, just to access a website or SharePoint.

+1 for a public apology, I think it would go a long way in improving MS-developer relationships. Getting out of the internet browser market would be good too, enterprise can keep IE6 for intranets as long as they like.

One certain way to upset developers is to constantly crow about how you are supporting standards, especially in a post about a hacked tool which encourages people to use IE6-standards.

+2 for some sort of roadmap on IE9.

@Jack, just because IE supports Group Policies does not mean that it cannot be standards compliant.

I am working on the "popup" problem with IETester. It is not corrected yet, I hope to correct it in a future release.

Regarding IETester, I would be happy to work with Microsoft, trying to make IETester a free stable product, or to integrate with SuperPreview, or to discuss something else, but they didn’t contact me yet.

I just got "indirect" feedback from them from different blogs saying IETester is bad :-O ,even if they have my email address.

I was referring to not dropping IE (as some are requesting from Microsoft). As long as Firefox, Chrome, Opera, etc continue to ignore enterprise networks. And with it, large scale deployments

Anybody working in an enterprise network will know what I mean. I like Firefox, and have installed it on most of my personal machines. But it’s impossible to deploy it on the networks I work on. standards compliant or not.

I already got some major flaming for requesting GPO and GPP support for Firefox at the Firefox dev forum. So support will not be included I guess

> The first thing Microsoft should do is just admit the horrible things they have done and apologise, over and over again,

I entirely agree. They should admit their bad, their wrong doing (which had nothing to do with negligence to begin with) and then they should publicly apologize. They should admit that their MS Front-Page and MS-Word authoring tools create invalid, non-compliant code (markup code and CSS code) and non-interoperable webpages.

> then get out of the browser market for good.

I now agree on that. For the reasons you listed and for other reasons (lack of useful [assistive] authoring tools, bad documentation, countless UAAG 1.0 failures, ATAG 1.0 failures, etc).

> They just can’t keep up. Their release cycle is too slow

True. In a post that IEBlog censored, I explained why releasing an IE 8.1 or an IE 8.5 version release was, IMO, the correct thing to do.

> and they are linked to OS releases.

True.

@billybob

> a hacked tool which encourages people to use IE6-standards.

Excellent. You nailed the most important issue with this blog post. Since feb. 2008, there has been a strong and utterly clear world-wide campain to phase out IE 6, to stop supporting IE 6. With this Microsoft Expression Web SuperPreview, Microsoft clearly contributes to maintain IE 6 as a browser version worthy of support. IE 6 is a non-web-standards compliant (HTML 4, CSS 2.1, DOM 1 & 2) browser version: with this Microsoft Expression Web SuperPreview, Microsoft continues to refuse to admit this.

You swore…I remember that clearly and I generally stop reading comments at that point. I remove cursing from my blog, YouTube channel, guestbook, etc. If it was a misguided though well intended comment I generally contact the person and politely let them know they are welcome to report…I even allow criticism if it’s well intended.

I think it would help you greatly to understand that the people who work on the IE team didn’t dictate that they were finished with IE6 years back, the higher-ups did. There have been plenty of comments about folks at Microsoft who were frustrated with the higher-ups decision to stop working on IE and it’s effects on standards. So when you make comments they are generally not seen by the people who dictate if IE will continue being worked on or not…it’s the people told what project (be it IE, Office, Windows, etc) that will read the comments.

That being said I share considerable number of criticisms about IE and Microsoft though I also think the situation is slowly improving. What the IE team needs are reading constructive comments…not sifting through posts that don’t help them and thus the industry we all work in.

As far as standards/CSS etc. support is concerned, IE has improved considerably in each new version. If IE9 could support CSS rounded corners and box shadows, as well has increase it’s JavaScript performance considerably, I would be a happy man indeed.

– I develop in Firefox 3.0 (oldest supported Gecko engine currently running: there were some CSS 2.1 corrections over CSS 2.0 that weren’t in it compared with Firefox 3.5)

– I test with KHTML/Webkit browsers, to be sure I’m not using Gecko-specific constructs. When I feel like it, I also test Opera.

– once I’m sure everything works fine in standards-abiding browsers, I fire a VM and test under IE 8 (developer tools), and I insert what I call ‘IE mode’ (an alternate code path) until it runs in IE 8 like it did in Firefox. Along the way, I also test Compatibility and Quirks modes.

– I open IEtester and test against all versions in it.

– If IEtester exhibits a strange reaction in a browser, I fire a VM with said browser installed, and I check against it.

Note that I keep in mind stuff like "don’t rely upon a flexible event model" or "don’t expect DOM modifications to be fast" or even "make sure the page’s HTML loads fast", since no easy/safe workarounds have been found against:

– IE’s lack of support for DOM2 events,

– IE’s lack of support for DOMContentLoaded (evil: requires hacky use of Jscript ‘write’ and ‘eval’ to obtain a similar effect), which would be a perfect

– IE’s hard crashing upon DOM modification on unclosed DOMs,

– IE’s incomplete support for innerHTML (a shame, since it actually introduced it).

And that’s only for IE 8; IE 7’s list of quirks is much longer (CPU use bugs/crashes, quirky objet property values’ copying…) and I won’t touch IE 6 with a 30-feet long pole…

This blog was originally set up to allow communication, but instead we have just been ignored as the IE team throws 1001 new headers and hacks at us to get things working in their browser.

Yes, we are that angry. Hours and hours are wasted every day because of IE. Maybe it is getting better but it is at a glacial pace. If all the other browsers can do it with only a few million dollars, how come MS can’t with their billions?

Standards ARE the holy grail, without them we have to write individually for each browser. Where would we be without other standards like ASCII, UTF-8, HTTP, IP, XML etc etc?

Personally, I have always thought that Microsoft is intentionally holding back the web to protect their other businesses. I was hoping that this blog would prove me wrong, but after 3 years I have been proven right.

Now things are at a critical stage, we have a few choices for our new web applications.

<canvas> is a part of the proposed HTML5 spec, which is not a standard as it has not been ratified. Neither has CSS3. Implementing proposed drafts can be dangerous as it is certainly possible that details will change.

Either SuperPreview has pretty damned bad support for caching (why is there no clear cache button?), or it is not compatible with the TwinHelix IE png fix. I kept on getting it to produce a crop instead of a scale, like the real IE6 had. 🙁

This blog welcomes and honors postings from anonymous people. This blog welcomes sarcastic, cynical posts from anyone. This blog is about filtering, censoring post that have more than one hyperlink.

> the IE team throws 1001 new headers and hacks at us to get things working in their browser.

Correction. Hacks to get webpages working in their IE 8 browser version. And to get webpages working in their IE 7 browser. And (very important) in their IE 6 browser version. That’s what Microsoft Expression Web Superpreview is all about. It’s based on a graphical interface (WYSIWYG): it is not based on learning and understanding the float model, rel. pos., abs. pos., inline model, code validity, etc. So that’s why I am convinced this authoring tool has nothing to do with web standards development. IE 6 and IE 7 browser versions have basically very little to do with conformance with web standards.

@ Mitch 74

> – IE’s hard crashing upon DOM modification on unclosed DOMs,

> – IE’s incomplete support for innerHTML

Bugs (including crash ones) on innerHTML, appendChild, insertBefore have been reported since 1999 by many people and there are some in Microsoft’s own Knowledge Base.

There are now several (at least 5) publicly available, entirely reproducible application crash bugs and application hang bugs known affecting IE 8; some were even found before (and reported months before) IE 8 final release and they were closed. If the IE release cycle is slow, then bugs on known, reproducible, testcase-ed application crash and application hang should have all been fixed before final release.

If IE Team members (Chris Wilson, Dean Hachamovitch, Eric Lawrence, etc, including Steve Guttman) were true believers of web standards, then they would have demanded a long time ago to have an IE blog that declares a strict DTD, that pass markup validation and CSS validation, that applies basic common sense WCAG guidelines at all times. They had the power to do so. It shouldn’t take 5 whole years to have basic coherence, fundamental consequence with a so-called Microsoft commitment with web standards.

What’s all the fuss about rounded corners? It’s still a DRAFT and it’s still not implemented the same way even across those browsers that supports it. Somehow a lot people seem to think it’s awful to use IE6-specific hacks, but it’s okay to write things like -webkit-border-radius, -moz-border-radius, border-radius at the same time and now wants another -ms-border-radius or something?

border-radius is still a DRAFT and you shouldn’t use it in production web pages. At least you shouldn’t use it until mozilla and webkit figures out how to implement it the same way so one don’t need to repeatedly write the rule three times to hope it work across different browsers that support it.

And the canvas tag implementations between Firefox, WebKit and Opera are so different already that it’d be WORSE if another browser goes into the fray and makes another different implementation.

I’d say let them settle down on the details of this FUTURE standard first, and let those "top standards-compliant browsers" make up their mind on WHOSE implementation should become the future standard, before anyone else trying to join in.

@dtrim: that’s what ‘working drafts’ are for: specifications advanced enough to be implemented in browsers, for testing – after that, it’s up to site makers to rely upon "experimental features" – or not.

But, waiting for specs to be written, implement an incompatible version then asking for the specification to be rewritten (or simply not implementing it) on the reason that ‘well, we need to support our non-compliant implementation for 10 years’ is not good either.

On the other hand, having IE unglued from Windows (meaning that a IE release won’t have to be supported for 10 years) might improve things in that matter.

When are DOM2 events coming to IE? They are part of a standard. When will IE support SVG? It is already a standard, that will be required to properly implement CSS3.

SVG is basically an arbitrary XHTML insert. IE does not really have to support it as you can support those using a plugin/addon as it the case with other arbitrary XML insterts. You can even create your own XML insertable markup and write an addon to support it.

@Jack: I don’t know about OWA 2010, but even if it’s great, that doesn’t make billybob wrong. It just means MS did a good job with that app, despite the limitations they had to work with. But the point remains: building such apps would be much easier and therefore more accessible if IE wasn’t holding back the web.

So, rather than implying billybob is just not doing it right, let’s be honest… Yeah, it’s still possible to make great web apps nowadays, but making things work with IE (especially 6) makes development longer and more frustrating, and the end result less good.

HTML and CSS is really easy in theory, it shouldn’t require that much "knowledge and experience" (also known as working around IE limitations and bugs).

That’s why people should not urge browsers to implement working draft. Those "standards leaders" like Mozilla, WebKit and Opera already have plenty of incompatible implementations on border-radius, canvas, video, audio, client-side storage, etc. etc. There’s already enough bickering around in HTML5, we really don’t need another incompatible "experimental draft implementation" joining in the fray.

That’s exactly the point I’m trying to say here, complaining IE not implementing a W3C-recommended web standard (or not implementing it correctly) is quite valid, but complaining IE not implementing a WORKING DRAFT like HTML5 and those working draft parts of CSS3 is just ridiculous.

obsolete for Ian Hickson, sure, since it seems for people like him anything out of experimental draft stage is obsolete already. Reminds me of those linguists saying that "any dictionary is obsolete the moment it’s published".

Generally speaking, something is only ready for general production use after it’s obsolete for those bleeding egde scientists. That’s why those WORKING DRAFT is not recommended for production use by W3C, and for site makers, writing -webkit-border-radius, -moz-border-radius and border-radius repeatedly is just as bad as writing IE6 specific hacks.

dtrim: except IE6 hacks can be hard to get right, be more or less clean / elegant, and you may have to go through the trouble of adding extra JS/HTC or images in some cases… and then that might end up breaking other things as a side effect.

While adding a simple CSS property is simple, readable, and as easily added as removed.

CSS at least, other browsers use the scheme ‘-brand-extension’ to implement a proposed CSS extension as proprietary; website authors are encouraged to use them for testing only (and they degrade gracefully) to explore their limitations. For the rest, see Stifu’s comment.

As for SVG being an XML insert, indeed; but then:

– if the resource isn’t supported by IE, why does IE try to load it? Answer: it’s XML – and IE is supposed to support XML.

– if IE supports XML, why do you get an error message when you load the SVG file, and not a graphical representation or a document tree? Answer: IE’s integrated msxml3 engine isn’t even XML 1.0 compliant… I really, really hoped a more recent version of msxml would be accessible in IE 8 (at least in Edge mode), but even then it didn’t work.

HTML extensions: well, here it’s rather easy; extensions in HTML are either tags or tag attributes; if they are not known, they are parsed as unnamed tags or properties. Moreover, most current browsers can be told how to treat new stuff like that by defining attributes in the DOM, and by defining CSS.

DOM extensions: well, it would be nice if IE supported them – that would mean someone could teach IE how to deal with W3C’s event model.

– if IE supports XML, why do you get an error message when you load the SVG file, and not a graphical representation or a document tree?

"

Because SVG’s MIME type is "image/svg+xml", not "application/xml". Therefore, IE (correctly) doesn’t sniff out the content as XML, which is actually in contrast to its normal (incorrect) behaviour of sniffing out HTML.

they are clearly "as bad" as they both ignore cross-browser compatibility. Site makers relying upon "experimental features" from working drafts on their production site is just the same as site makers writing IE-only sites, they both ignore cross-browser compatibility.

Writing test sites showcasing experimental features is okay, but writing production sites relying on those working draft experimental features is just the same kind of bad behavior as IE-only sites.

Writing a site with experimental working draft features to make it look good on those browsers that support them, nice, but complaining some other browser not supporting these experimental working draft feature is just downright ridiculous, since those features are not recommended for production use by W3C and there’s nothing wrong for browsers not supporting them, until they finalize and become standards that is.

you still miss the point. The point is, I’ll say it again, complaining IE not implementing a W3C-recommended web standard (or not implementing it correctly) is quite valid, but complaining IE not implementing a WORKING DRAFT like HTML5 and those working draft parts of CSS3 is just ridiculous.

So complaining IE not supporting things like border-radius, canvas, video and audio, etc. is just downright ridiculous.

It’s nice for some browsers to support some working draft experimental features for testing, and it’s nothing wrong for other browsers not supporting them, until they become standards.

For example, it’d be nice if Opera can support multiple backgrounds and if Firefox can support Web Forms 2.0, but until those specs finalize and becomes standards, complaining browsers not supporting them is just not relevant.

And for people like Ian Hickson, something he can’t use for bickering around with his fellow scientists is obsolete already.

@dtrim – you seem to be confusing "idealistic" and "realistic" concepts.

Idealistically all browsers should support the same set of web standards but Realistically they don’t.

You can complain all you want that CSS3 isn’t an official spec all you want but the "gist" of it has been known for ages and those browsers that plan to lead the way in the future are already well ahead by implementing parts of it.

The simple border-radius (all all the sub-option properties) is one of those properties in CSS3 that everybody wants and needs. Developers have the option to push forward with these properties and start using them right away. If unsure, they can always used the vendor specific properties if they are worried about them changing down the road. e.g. -moz-border-radius:5px;

Unfortunately because MSFT has been playing catchup for 5 years they can’t even implement most of the CSS3 features even if they wanted to. Worse yet, when IE9 comes out if CSS3 hasn’t long since been a standard they won’t implement the border-radius property claiming that it isn’t a spec yet – and once again they (and MSIE) will be fully responsible for holding back the web – yet again.

Like many developers I’ve given up on IE – they can take their time or start implementing features properly whenever they want – I don’t care. I will code my sites so that they work and look great in Firefox, Chrome, Opera & Safari – and if they don’t look good or even fail to work in IE – then I don’t give a hoot! I’m not supporting a legacy browser that can’t keep up.

you are wrong, this has nothing to do with "idealistic" and "realistic", and I DID NOT complain about anything. I clearly DID NOT complain anything about "CSS3 isn’t an official spec", that’s just stating a fact, and I’m just saying people should STOP COMPLAINING about browsers not supporting WORKING DRAFT. There’s nothing wrong with a browser not supporting a working draft, complaining about it is just ridiculous, period.

you should read better before replying. And what you do is irrelevant here, IE doesn’t support border-radius, Opera doesn’t support border-radius, Firefox doesn’t support HTML5 Forms (Web Forms 2.0), etc. etc. That’s okay because those are not standards yet.

And if CSS3 can’t finalize and become a standard before IE9 comes out, that most likely has nothing to do with IE, since W3C doesn’t really care much about IE when releasing standards. You are just being ridiculous to claim that "they (and MSIE) will be fully responsible for holding back the web" for CSS3 not able to finalize.

IE does hold back the web, but not for the reasons you stated, and you being illogical doesn’t help moving the web forward neither.

"If unsure, they can always used the vendor specific properties if they are worried about them changing down the road. e.g. -moz-border-radius:5px;"

Actually, currently people MUST use vendor specific properties for border-radius to work, simply writing border-radius:5px; will just be ignored by everything out there. There’s nothing unsure in this. If you don’t write -moz-border-radius:5px; and -webkit-border-radius:5px; repeatedly, you won’t get it to work even for those browsers that support this experimental feature, that’s why it’s clearly just for testing, not for production use.

those -webkit-border-radius, -moz-border-radius things are only acceptable because they are experimental features for testing only. If people are required to write those vendor specific rules repeatedly for production sites, that would be simply unacceptable and downright WRONG, just as bad as IE6 hacks. Luckily W3C is logical enough to make it clear that they are for testing only, that’s why they are okay. For production use, they are just bad like writing those IE6-specific hacks, which one SHOULD NOT need to write in the first place.

dtrim: you’re blowing things way out of proportions. In the end, if you use the experimental border-radius property in your pages, it all boils down to: best-case scenario: the rounded corners work, worst-case scenario: the rounded corners don’t work. End of story. This won’t make browsers crash or whatever, no people will die, and so on.

By using them, for example, I could find a bug in Firefox that I reported, which is the whole point, as Mitch highlighted.

IE6 hacks are only good for one thing: IE6. You could spend a while getting an IE6 hack right, and then find out IE7 may need a slightly different one. Using experimental CSS3 properties is much easier and doesn’t kill your productivity, and don’t target a specific browser but specific rendering engines.

Oh, and on a side note, earlier versions of IETester weren’t quite as crash happy as the latest ones.

I would only go as far as to say that Microsoft is interested in SVG, and *considers* supporting it. Whether they will depends on many technical factors (what needs to be implemented, at which layer does each part need to be implemented, how should it be implemented, what can be reused, etc.) and perhaps even financial ones (must another engine be licensed, etc.).

BTW, to whoever maintains the IE Blog… I seem to be unable to post with my account (of the same name), but only after logging out and writing it explicitly in the comment (as an "anonymous" name). Is it just me, or is there something more to it?

Oh… so I suppose you know the people that maintain the blogs.msdn.com software? I was left with the impression that you (and/or the MSIE team in general) aren’t completely sure who at Microsoft maintains it.

Have you also talked to them about making the blogs (or at least this one) validate? Or at least make a switch from XHTML 1.0 Frameset to XHTML 1.0 Transitional (which will certainly reduce the errors list)? I know fore sure that a few people asked for this (I don’t really remember if *I* did, but I’m sure *for* it).

I remember one day recently (I think it was 3 Semptember), the IE Blog was replaced by what seemed to be a nice attempt at a "Web 2.0-ish blog"… was that their (failed BTW) attempt to make this blog validate (and I say failed because even that new theme had a lot of validator warnings)?

I am completely aware of that. My question was whether you actually presented it to them as an issue, in the same sence that we report issues about IE to the IE team. A "yes" from you, at least from my point of view, will NOT mean that we’ll have the IE Blog validate, but it will be enough to know that you care, which is the first step it making them eventually do it.

Today, we’re releasing an early version of Google Chrome Frame, an open source plug-in that brings HTML5 and other open web technologies to Internet Explorer.

We’re building Google Chrome Frame to help web developers deliver faster, richer applications like Google Wave. Recent JavaScript performance improvements and the emergence of HTML5 have enabled web applications to do things that could previously only be done by desktop software. One challenge developers face in using these new technologies is that they are not yet supported by Internet Explorer. Developers can’t afford to ignore IE — most people use some version of IE — so they end up spending lots of time implementing work-arounds or limiting the functionality of their apps.

With Google Chrome Frame, developers can now take advantage of the latest open web technologies, even in Internet Explorer. From a faster Javascript engine, to support for current web technologies like HTML5’s offline capabilities and <canvas>, to modern CSS/Layout handling, Google Chrome Frame enables these features within IE with no additional coding or testing for different browser versions.

To start using Google Chrome Frame, all developers need to do is to add a single tag:

<meta equiv="X-UA-Compatible" content="chrome=1">

When Google Chrome Frame detects this tag it switches automatically to using Google Chrome’s speedy WebKit-based rendering engine. It’s that easy. For users, installing Google Chrome Frame will allow them to seamlessly enjoy modern web apps at blazing speeds, through the familiar interface of the version of IE that they are currently using.

We believe that Google Chrome Frame makes life easier for web developers as well as users. While this is still an early version intended for developers, our team invites you to try out this for your site. You can start by reading our documentation. Please share your feedback in our discussion group and file any bugs you find through the Chromium issue tracker.

@Chrome – Wow! that is fantastic news! I remember watching the Google Wave demos wondering how on earth are they gonna get this to run in IE? Now I know! Kudos for them not waiting for Microsoft to fix IE and just jumping in and making IE better by installing their own browser within.

@Mitch, do you smoke all propaganda that Google hands you? Do you even think critically about their claims for a millisecond?

Try out ChromeFrame and you’ll see that the phishing/malware filter isn’t run, because it’s not IE showing the pages anymore. Same for the XSS blocker, I bet.

Every version of Chrome has had a number of security bugs, and adding it at least doubles your attack surface, with yet another html parser, duplicate copies of all image decoders, xml parsers, javascript parsers, etc, etc, etc.

It’s a fun toy that shows off how flexible IE is, but no corporation who cares about security would ever allow it within their environment.

End users… well, we know they’ll install any random thing that looks shiny.

Of course, it’s probably all okay because ChromeFrame is currently so buggy that it can’t even download files, so I can’t imagine most people will keep it installed for long.

I don’t exactly have a way to test if the phishing and SmartScreen get executed and if they still block malware pages, but I can tell you for sure that the XSS blocker runs. Just type in a script element as a query string to this very page, and you’ll see it in action.

ChromeFrame is only executed when the appropriate meta is added, so I’d guess the phishing filter and SmartScreen is executed as well. This also lets the web developer to not enable it when a page contains files to be downloaded… alternatively, they may avoid using it altogether, until it becomes more stable, and removes these known issues (which is what I intend to do).

The ie8demos web site doesn’t include demoes for when the CromeFrame meta is set, so we can’t really make certain that the phishing and/or SmartScreen filter don’t get executed when the meta is present. I’d assume they still get executed, because they react on the URL of the web page, not on its rendering and/or markup. Show me a web page that requests CromeFrame AND activates the phishing and/or SmartScreen filter without it, and I’ll accept that you’re right.

I think I can now see how the XSS filter will be useless though. The XSS filter works by not executing any scripts on the vulnerable web page, and CromeFrame may not respect notifications from it (assuming the XSS filter gives out notifications to plug-ins to begin with; I don’t know if that’s the case).

And I’d agree that if a vulnerability is in Crome’s parsing, rendering or scripting engines, users are exposed to them. Hopefully, CromeFrame will be just as pushy for updates as Crome itself (if not more), so that these vulnerabilities are as minimized as possible.

Well, that changes the URI, so yeah… the page will be bypassed by the phishing and SmartScreen filters, because the URI scheme is not one that the phishing filter and/or SmartScreen filter knows. Even if they did checked it, the URI is still not a "one to one" match to the one in the database, so it will always turn negative.

If using CromeFrame *with a meta element in your page* (and not with the "cf:" URI scheme) does indeed cause the phishing and/or SmartScreen filter to be bypassed, I think it will be a good thing for the IE team to write about in a future blog post, after they’ve done some internal research on the subject (since they can add test URLs do a page they control, and we can’t).

In short, if you open a Chromeframe tab in IE 8, IE actually opens an iexplore.exe process (as usual), which loads an ActiveX control (surrounded by all the protections IE has against ActiveX exploits) which loads Chrome.exe (which has, itself, its own security system) which THEN runs the renderin thread. On top of that, it supports NX (if IE does, and IE 8 does indeed; I activated NX for all processes in WinXP, and CF still ran nicely), address range randomization (Vista/Seven)…

So, not only does CF still keep IE’s security measures, it adds an extra layer on top of it! To exploit it, you’d need to:

– find a bug in Webkit; okay, that’s not too difficult (but this is true of any engine, Trident included),

– break outside of Chrome’s bottle; that’s said to be tricky even by top hackers – those who do, do it with Flash,

– break outside of that IE process’ bottle; that is also said to be quite tricky on IE 8 (latest one, which used .Net, doesn’t work anymore),

– break outside of IE’s restricted right process.

It could be done, sure – but that would require breaking out of ‘normal’ IE anyway!

In fact, Chrome Frame may be the only way to make IE 6 even remotely secure.

And for your information, I don’t smoke, I only drink real tea (not that crappy Lipton thingie), I don’t do drugs, I don’t even use Chrome (I run Linux, which pretty much means Firefox for now), so I’m no Google fanboy like you seem to think.

I still say that they accomplish a pretty nifty thing with their embeddable engine.

Why isn’t the Gecko engine used/supported? Firefox and derivatives have a third of the market today form browsers that cannot be ignored. While it’s great to see IE migration made easier, it would be even better to check for cross-browser interoperability. Is this a goal for Microsoft to achieve?

@Fred: I think these days "alt-browser" is a bit of a stretch. Everyone knows what Firefox, Safari and Chrome are… they are the browsers they use at home that they can’t use at the office due to goofy corporate IT policies.

I could rant on here as a non-IE fanboy for sure but that’s not why I’m here. I come here for updates on IE, hoping that the browser is moving in the right direction.

The problem is the post title "Supporting Web Standards with SuperPreview". If Steve Guttman had titled it, "Using SuperPreview to debug rendering discrepancies" then there wouldn’t be a need to argue in the comments.

However when you state you are using SuperPreview to support Web Standards then all you are going to get is griping!

It doesn’t solve the problems between IE6,7,8 it doesn’t handle interaction (e.g. hover and dynamic javascript events and page changes) and thus is a crippled development tool at best. Throw in the fact you have to pay to get a Firefox rendering in the mix and you now have a toy that can’t really do anything for you.

For rendering differences WITH JavaScript interaction you are MUCH better off using IETester. Or if you are real hardcore, have hard drive space and time to waste, use a bunch of Virtual Machines (or VPC) to test in all browsers from one PC.

The reality is that developers these days develop and test in a NON-IE browser first. Double check that it works in all the other non-IE browsers, and then, they check it out in IE8, then IE7, then IE6 (if they have to support back that far) Of course unless they have a great framework in place to abstract away all the IE bugs, they will then spend the next 2-3 days trying to figure out why IEx is completely messing up some portion of the page/application.

We then get annoyed, and come here looking for answers, and all we find is MSFT self-promotion of tools that won’t solve any of our problems.

And thus we have only one way to vent our frustration – we write up a little rant here on the IE Blog about how 1 or more things in IE are so horribly broken that they make our daily lives a nightmare of bug tracking.

…but I digress – I didn’t come here to rant… I came here because the topic started with the words… "Supporting Web Standards" and then it went downhill from there – very quickly.

The best news was in the comments. Google Frame looks very promising and sure to solve most of the IE problems. All we need to do now is get our end users to upgrade their IE by installing Google Frame and then we don’t have to worry about IE anymore.

@Fred – thanks for taking the time to read all of my comments it really shows.

I’m sorry my reality doesn’t match your fantasy. In the windows world everyone has heard of Firefox and they have heard of chrome too because every time they visit a Google site, Google suggests that they can download the super fast chrome browser or that their Gmail will run faster in chrome.

Safari? maybe not so much.. but if they have an iPod (I mean, come on, who doesn’t?!) they likely installed iTunes… and due to Apple’s questionable "updater" they likely have Safari, Bonjour, and MobileMe installed too.

Keep in mind that with so many Macs out there these days, where Safari is the defacto standard, people tend to find out about it.

Am I calling some corporate policies "goofy"? you bet! Installing a better, more secure browser than IE on a windows system is a no-brainer. I’ve been at Security IT conferences where IT Admins that didn’t allow Firefox installs were quickly informed just how insecure IE is and what real-world benefits their network and users would gain from installing Firefox. It was very enlightening.

Like many that read this blog – if the office I worked at didn’t allow me to install Firefox I would hand in my 2 weeks notice on the spot – there’s no reason whatsoever that an end user shouldn’t be allowed to use the best, most secure tools out there.

Your point on the "known" security issues with Google Chrome… care to elaborate? URLs would be handy.

As for Google Frame… wrapped up inside IE, it is actually more secure than either browser is alone – so I doubt concerns about security will stop users from installing Google Frame.

As Mitch 74 pointed out, abusing a bug in Google Chrome – when running in as a Google Frame, requires an extremely elaborate hack to own a PC.

Thanks for the MS fanboy point of view though! Its always enlightening to read what FUD is spreading around the InterWebs on a daily basis.

The fact that ChromeFrame doesn’t respect the IE privacy and security features is documented in Google’s bug database. The more troubling factor is the remarks suggesting that such holes might be "by design."

@Stan: I’m impressed at how much time you’re willing to waste typing things up. Spend half as much time reading as you do writing and you’ll learn that statements like "more secure than either browser is alone" are completely incorrect; ChromeFrame is less secure than *either* Chrome or IE alone. You don’t make a product more secure by adding additional vulnerabilities to it.