IE8 Standards Mode Is Opt-in
IE8 Standards Mode Is Opt-in
Chris Wilson confirmed today on the IEBlog that for a site to render in standards-compliant mode in IE8 it will need to include a specific meta tag: “Quirks mode” remains the same, and [will stay] compatible with current content. “Standards mode” remains the same as IE7, and [will stay] compatible with current content. If you (the page developer) […]
Chris Wilson confirmed today on the IEBlog that for a site to render in standards-compliant mode in IE8 it will need to include a specific meta tag:
- “Quirks mode” remains the same, and [will stay] compatible with current content.
- “Standards mode” remains the same as IE7, and [will stay] compatible with current content.
- If you (the page developer) really want the best standards support IE8 can give, you can get it by inserting a simple
metaelement.
The meta tag, also documented by Aaron Gustafson in the latest issue of A List Apart (with careful justification and support) looks like this:
While I concede that, in order to retain backwards compatibility with the sites of yesterday (and of five years ago), opting in to render a page in standards-mode in IE8 seems the only sensible option, one thing really irka me about this approach:
Hardcoding a reference to a specific browser as a necessary part of the page’s markup feels plain dirty.
It’s one thing to specify a character encoding or the language used by the page, but the agent with which it is compatible? Fundamentally and philosophically it just makes sense for a page to be completely browser-agnostic. In fact, the sheer mention of a browser in a page could be interpreted as a geek form of advertising, while other browsers pay the penalty for being better at adhering to the W3C specs. Will other browsers follow suit, such that web developers find it necessary to write something like this?
Still, I guess it beats using conditional comments.
This article provided by sitepoint.com.
Microsoft JavaScript Memory Leak Detector
Paolo Severini, a Microsoft employee in Dublin, has build a JavaScript Memory Leak Detector that detects leaks with knowledge of the difference between IE 6 and IE 7. How does it work? Like any IE Band, the JavaScript Memory Leak Detector is a COM in-process DLL loaded in the Internet Explorer process. The fact of living inside […]
Paolo Severini, a Microsoft employee in Dublin, has build a JavaScript Memory Leak Detector that detects leaks with knowledge of the difference between IE 6 and IE 7.
How does it work?
Like any IE Band, the JavaScript Memory Leak Detector is a COM in-process DLL loaded in the Internet Explorer process. The fact of living inside the IE process allows it to easily intercept some of the API calls made by the IE code. In this case, we are interested in intercepting every call that creates a Jscript engine.
The Jscript engine is a COM object, and it is instantiated by Trident (mshtml.dll) with a call to CoCreateInstance(). Therefore, the first operation made by the tool will be to intercept the calls to CoCreateInstance made by the mshtml module. There are a few ways to implement this API hooking; in this case the simple technique of overwriting the module Import Table in memory works perfectly. (See Robbins’ “Debugging Applications” for more details).
At this point we can substitute our own Jscript engine in place of the real engine. By implementing all the ActiveScript interfaces exposed by a Jscript engine and delegating all the calls to an instance of the real Jscript engine, the tool can transparently intercept all the interactions between Trident and Javascript and still have Internet Explorer to run correctly.
Now, a Jscript engine by itself has no notions of Internet Explorer and its DOM objects. It is IE that registers the root (window) object to the engine and loads into the engine all the scripts contained or loaded by a HTML document. Since we are intercepting all the calls to Jscript, we can thus have a reference to all the DOM objects that are passed to or used by a Javascript function.
The technique to do this is a bit tricky. A DOM object is passed to (and accessed by) Jscript through an IDispatch interface; so for each new object that we meet we create a fake COM object that works as interceptor (or wrapper), exposing IDispatch and delegating the calls to the real (contained) IDispatch object.
Every time a method or property is called to a DOM element by JavaScript, the call is actually made to our wrapper and then delegated to the real object. The wrapper can analyse the method in/out parameters and return value, looking for other IDispatch pointers that represent new DOM objects. If it finds a new IDispatch pointer not yet met, we know that this object will now be visible to the JavaScript code, and we need to build another wrapper and pass it to JavaScript in its place. In the end, every JavaScript function will access DOM objects only through these wrappers and the tool will have complete control over the script execution.
IE8 and Doctype switching
The topic of this week has been IE8s new rendering mode, and the strange way to trigger it. As usual, I’ve decided not to comment right away, and instead first read what others are saying and try to form an opinion. I believe the best articles that talks about the switch are these: Legacy, by James […]
Ext 2.0.1 Released, Community Projects Continue to Grow
The Ext team released version 2.0.1 of Ext JS. This is a maintenance release that fixes several issues with the 2.0 release. Some notable issues that have been addressed include: Fixed various overflow/scroll issues related to form fields and grid Workaround included for the Firefox 2.0/Mac overflow:auto invisible scrollbar bug Fixed several issues related to destroying […]
The Ext team released version 2.0.1 of Ext JS. This is a maintenance release that fixes several issues with the 2.0 release. Some notable issues that have been addressed include:
- Fixed various overflow/scroll issues related to form fields and grid
- Workaround included for the Firefox 2.0/Mac overflow:auto invisible scrollbar bug
- Fixed several issues related to destroying form elements
- Multiple GridView and GroupingView fixes
- Various other minor bug fixes and documentation updates
For complete details on what’s changed, please have a look at the 2.0.1 release notes.
In addition, new projects based around the Ext framework continue to sprout up. Several Java and ColdFusion server-side initiatives have taken root demonstrating the growth of the Ext community.
Projects such as MyGWT and the recent ExtTLD are helping Java developers leverage Ext via server-side implementations while ColdFusion-based ColdExt and cfExt are allowing CF developers to use Ext 2.0. This is especially important for ColdFusion developers who are either limited to ColdFusion 8’s Ext v1.0 implementation or must implement a strictly client-side solution in prior versions of the application server.