Check Out the New Developer Tools Tutorials

Article
07/23/2009

I’d like to invite you to check out the new tutorials added to the Developer Tools content. These tutorials are written to help you quickly learn how to use the Developer Tools to solve Web page issues. Each tutorial is set up to focus on a programming problem to solve, such as changing text on the page, update a CSS class, or inspect a Jscript variable. You can follow the step-by-step instructions provided to learn how to use the Developer Tools to solve these and similar problems.

Hi, my name is Duc “Cash” Vo, a Programmer Writer on the Internet Explorer team and I’m excited about developing content for the Developer Tools. As a Web developer, I’ve long wished for an integrated developer tools, and I got my wish in IE8! This is my first time posting to the IEBlog, and I look forward to discussing features and improvements for the Developer Tools with this community.

With the release of each beta for Internet Explorer 8, you might have read about the Developer Tools’ features and benefits on MSDN,and you may even have tried them out. (But just in case, if you haven’t done so, it may be to your benefit to check out the Developer Tools on MSDN now before you proceed.) With the final release of IE8, we’ve written a series of tutorials and created a “sandbox” for you to play in.

We categorize tutorial topics based on your Web site’s problem sets that you can resolve using the Developer Tools. We also title our topics based on tasks you as a web developer might want to perform. For example, under the HTML section, you’ll see topics such as:

I want to change the Item header to Item Description.
I want to center align all of the prices.
I want my Price Total field be a read-only element.

Similarly, under the CSS section, you’ll see topics such as:

I want to update the .listingsTable class.
I want to add a new class .price and have it apply to the Price column.

Head over to the Developer Tools tutorials at https://msdn.microsoft.com/en-us/library/dd565631(VS.85).aspx and have some fun. Once you’re done, we’d love to hear about your experiences using these tutorials. Let us know how can we make them more useful for you, and what scenarios and skills would you like us to add.

Until next time,

Duc (Cash) Vo
Programmer Writer
Internet Explorer

Comments

Anonymous
July 23, 2009
any new news on ie next now that windows 7 has rtmed
Anonymous
July 23, 2009
Funny thing: I just compared your tool with other ones http://www.favbrowser.com/internet-explorer-developer-tools-vs-firefox-firebug-vs-safari-web-inspector-vs-opera-dragonfly/
Anonymous
July 23, 2009
What's a Jscript variable? is that like a JavaScript variable? if so don't bother using MS-only names when talking about web development. Call it JavaScript or don't talk about it at all. Nothing is more frustrating to us developers than to hear MS try to apply their own name on something that is already widespread. Its as bad as hearing people talking about bing'ing things. You can't be taken seriously when you talk like this.
Anonymous
July 23, 2009
@Harvey: Let me help you understand. JScript is Microsoft's implementation of ECMAScript. JavaScript is Mozilla/Netscape's implementation. If you think the semantics are the most important thing, you probably should be using the term ECMAScript. But, I don't think anyone, anywhere, is likely to be confused or frustrated by this post.
Anonymous
July 23, 2009
Paul: Your post frustrates me, and your comment does as well. JScript and JavaScript might have referred to implementations in the mid '90s, but not in the last ten years. Today, JavaScript refers to the scripting language that extends ECMAScript, as implemented by browsers. Mozilla's implementation of JavaScript has its own name: "SpiderMonkey" (technically, Mozilla has two engines, since they also host an engine written in Java: "Rhino"). WebKit has its own JavaScript implementation, as does Opera. IE may only support its own backward almost-JavaScript language ("JScript"), but we all write JavaScript. When we debug scripts in IE, we debug JavaScript. When we read articles on Ajaxian.com on some cool client-side scripting, we certainly don't go to the "JScript" category.
Anonymous
July 23, 2009
The comment has been removed
Anonymous
July 23, 2009
That should have read "This post frustrates me, and your comment does as well." A long day of debugging JavaScript in IE affects my concentration, I guess.
Anonymous
July 23, 2009
The comment has been removed
Anonymous
July 23, 2009
@The Hater "A long day of debugging JavaScript in IE affects my concentration, I guess." I though that IE had JScript not Javascript. Maybe thats why it tool you all day.
Anonymous
July 23, 2009
Thanks for the links. I tried changing the onsubmit property of a form and it didn't work. Forgot I could just use the console and do it that way :P. (yeah, I generally avoid the attribute-based events stuff but you encounter all sorts of fun in older code) @Mike ROFL @Harvey Mountain out of a molehill. @The Hater So is it "backwards Almost-JavaScript" or JavaScript? Have you made up your mind yet? You could just call it JScript...
Anonymous
July 24, 2009
How to check the supportivity of tags in IE such as <basefont> in IE8
Anonymous
July 24, 2009
The comment has been removed
Anonymous
July 24, 2009
@Jackie - the best resource I know of for this is SitePoint. http://reference.sitepoint.com/html/basefont For every tag/attribute available (as well as CSS/JavaScript) they list all the info you'll normally need. PS for the record though, it looks like it hasn't been updated for IE8 yet. :-(
Anonymous
July 24, 2009
The comment has been removed
Anonymous
July 25, 2009
The comment has been removed
Anonymous
July 25, 2009
@laranson: When you open a plain XML file, it will immediately show any errors without an information bar. If there are no errors, then it will show an information bar that does not block your ability to view the file in any way; the information bar notifies you that the script (which is used to provide the expand/collapse feature of the nodes) has been blocked due to the setting I described. Of course, there exist far better XML viewing/debugging tools than any web browser provides, including Visual Studio and many free tools.
Anonymous
July 25, 2009
http://www.msie.com/ You guys planning on doing anything to the RegCure people using that domain? Interesting claims (nonsense) they're making:
"Repairs ALL errors"
"Speeds Up PC Performance by Over 100%!"
Anonymous
July 26, 2009
@DomainSquatter: I don't see how they could, since they don't have a trademark on MSIE-- it's called "Windows Internet Explorer" these days anyway.
Anonymous
July 26, 2009
This is definitely better than what I've used before
Anonymous
July 26, 2009
Jackie, I also use sitepoint for that, it works well.
Anonymous
July 26, 2009
Will the team start to reply to open Connect bugs soon so we can start to see what is being looked at for the next version? Will we know if the next version will be a quicker to rtm .5 release or a full blown but longer to market full version? in the next beta will the offical testers get more than one non public interum build like at least priveate build in between each public build?
Anonymous
July 27, 2009
@Harvey - "JavaScript" is trademarked by Sun (see: http://www.sun.com/suntrademarks/ ). MS probably calls their implementation JScript to avoid legal issues.
Anonymous
July 27, 2009
The comment has been removed
Anonymous
July 27, 2009
The comment has been removed
Anonymous
July 27, 2009
A few corrections... Javascript is called thus because it was, at the beginning, a language developed by Netscape to allow Java applets to interact with a page's content (all there was before was static HTML tag soup, see - and the DOM wasn't even a notion). It wasn't supposed to become a standalone programming language, but well, it did; and because a language works best when it's normalized, it was standardized through ECMA and nicknamed ECMAscript; and Javascript is ECMAscript-compliant, like ActionScript is. And Jscript is too, supposedly. Now however, there are several implementations of Javascript:

Chrome's Javascript engine is V8
Safari's Javascript engine is JavaScriptCore, based on KJS
Firefox's Javascript engine is SpiderMonkey, expanded through TraceMonkey All of these recognize MIME-types such as 'application/ecmascript' or 'text/ecmascript' or (legacy) 'text/javascript'; they ARE Javascript engines, and more often than not they base themselves off Mozilla's documentation for their own Javascript language (it's a safe bet, nowadays, to program to Javascript version 1.5 to 1.7 in any of these browsers). Jscript is Microsoft's ECMAscript-compliant engine. It is NOT Javascript, eventhough the only MIME-type it understands is 'text/javascript'; it has proprietary extensions such as conditional compilation and isn't based off Mozilla's Javascript language description; instead, it's based off ECMAscript with a few legacy Netscape extensions. In short, current Web developers that program client-side software, without doing browser detection nor object fallback program to a common subset to both languages: ECMAscript loaded through legacy 'text/javascript' MIME-type with legacy Netscape extensions and core DOM 1. Mind you, this is enough to do some nifty stuff already; but it would, of course, be much better if IE actually supported Javascript (and, just because event cascading and bubbling is nice and impossible to emulate properly using IE's event object, DOM 2 events...). When one actually DOES Javascript now, then either IE is left out, or a corresponding bit of Jscript is written and there's browser detection and object fallback somewhere. The objection that can be made to this MS-created documentation is thus that elements that are part of ECMAscript should be names such, and MS-specific extensions should be referred to as Jscript elements - that would help TREMENDOUSLY in developing cross-browser code, as those parts labeled 'ECMAscript' are cross-browser, while Jscript ones are IE-specific.

Anonymous
July 28, 2009
@Toman - As far as I'm concerned, you could call all client-side scripts "bananas". I look at someone's code to see if they are any good. "I'd hate to see the reaction if you went for a development position interview and when asked about your web expertise you answered with "I've been programming in JScript for 6 years"
Anonymous
July 28, 2009
Some of my users (that have upgraded to IE8) are reporting that between loads of pages on the same site (with very little content change) are now flashing white before showing the next page. This doesn't occur in IE7 or IE6 or any other browser. Is this a known issue? Is there a fix? Thanks
Anonymous
July 28, 2009
@Mitch74: When you're going to write "corrections," I hope you'll agree that accuracy should be your goal. Unfortunately, nearly every statement you made is incorrect, and since you have cited no sources, it leads one to wonder whether you were misinformed or simply decided to make this stuff up. Your history of the language is entirely inaccurate, the language isn't "nicknamed" ECMAScript-- it's named that (Google "ECMA 262"), IE recognizes more than one MIME-type, DOM eventing is NOT a part of the scripting language at all, etc, etc, etc. Please don't write if you can't be bothered to write accurate remarks. @Philip: Website visitors say all sorts of things. You should provide URLs that reproduce the problem and explain what debugging you've done so far.
Anonymous
July 28, 2009
When viewing the source of a page in IE the text-highlighting is very anoying. Not the coloring, but the physical text drag-to-select highlighting. I dare you to try and select an attribute value that starts with a slash. e.g. [sometag attributeName="/attributeValue" Place your cursor (I-bar) just inside the double quote and drag to the right. You end up selecting {="/attributeValue} how un-user friendly is that?! why would anyone want to select ="/text as a value. Try selecting it backwards?.. nope! same bug!
Anonymous
July 28, 2009
The comment has been removed
Anonymous
July 28, 2009
[I'd love to add this comment to an on-topic post, but they get closed rather quickly, so I'm forced to simply ask at the newest post.] Can the IE team explain why the .NET CLR details are cluttering up the user agent string? I can't figure out how the information is relevant in the web environment. We've got user agent strings pushing past FOUR HUNDRED CHARACTERS in length. If you are trying to communicate browser capabilities, THERE'S A HEADER FOR THAT: HTTP Accept. The same goes for Media Center PC, InfoPath, OfficeLiveConnector, OfficeLivePatch, and MSN Optimized, and probably dozens of others. You are filling up our logs, and congesting the tubes with what can only be considered SPAM. Also: It's time to get rid of the "Mozilla/4.0 (compatible;" nonsense.
Anonymous
July 28, 2009
Just to illustrate: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; GTB6; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; OfficeLiveConnector.1.3; OfficeLivePatch.0.0) Seriously? And why is Mozilla/4.0 in there twice?
Anonymous
July 28, 2009
@Brianary - I agree! There is so much garbage stuffed in there that finding anything meaningful is almost impossible. Mine is: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; .NET CLR 1.1.4322; InfoPath.2) Now if I read this correctly I'm running MSIE 8.0. no, wait, thats MSIE 6.0 no, wait, thats Windows NT 5.1 no, wait, Trident/4.0 no, wait, Mozilla/4.0 no, wait, InfoPath no, wait, .Net CLR 1.1.4322 oh, silly me I should check the appName and appVersion... that would make it more clear. .appName: "Microsoft Internet Explorer" - fine .appVersion: "4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; .NET CLR 1.1.4322; InfoPath.2)" - yeah not so much on the helpful department. The first number I get to is 4.0 which makes no sense at all in 2009. oh wait, I'll use the proprietary window.clientInformation to get real simple details!...... not a chance. Ugh!
Anonymous
July 28, 2009
@Brianary: We've talked in the past about how user-agent bloat is a problem, and specifically recommended that folks not spam the UA String, as described here: http://blogs.msdn.com/ie/archive/2009/01/09/the-internet-explorer-8-user-agent-string-updated-edition.aspx The case where you're seeing the "Mozilla/4.0" twice is a machine on which some tool or administrator thought they could emulate IE6 by putting the full IE6 UA string in the registry; this obviously doesn't work properly. Your point that many Microsoft applications spam the UA is absolutely true, and it's the subject of ongoing conversations with the teams doing so. We have strongly suggested that teams refrain from doing this. The .NET team communicates felt it necessary to communicate version information so that websites could target proper versions of the CLR with WPF/ClickOnce content. We are working with them to find better ways for them to achieve their needs. However, your suggestion that applications spam the Accept header is not an improvement, and Accept-spamming is source of similar problems as described here: http://blogs.msdn.com/ieinternals/archive/2009/07/01/IE-and-the-Accept-Header.aspx
Anonymous
July 28, 2009
The comment has been removed
Anonymous
July 28, 2009
Since the last time I brought this up, not only have things gotten no better, they've gotten dramatically worse! The "Mozilla/4.0 (compatible;" needs to go, obviously. Whether absolutely any string (such as a duplicate user agent string) should be allowed by any random toolbar or BHO is probably outside the scope of this forum, but at the very, very least someone within Microsoft should be asking whether Zune, OfficeLiveConnector, OfficeLivePatch, Media Center PC, MSN Optimized, etc. really need to bloat every single request, and whether it needs to be in the user agent header, which tends to be persisted to logfiles on disk. It sounds like you are trying to do that, and I hope you get some traction. Until then, can you explain why my other posts were removed, particularly the one in which I proposed a protest against the bloated IE user agent string by including the three longest MSIE user agent strings from web server logs at the top of all comments and communications to Microsoft?
Anonymous
July 28, 2009
Brianary: if you don't wanna get modded, maybe you should avoid posting (basically) the same rant over and over again, and suggesting that others spam as well?
Anonymous
July 28, 2009
@Ian: "[ECMA-262] defines the ECMAscript scripting language". ECMAscript is a perfect implementation of the ECMA-262 specification - ECMAscript is NOT the standard, it's its 1-to-1 implementation: strictly speaking it is 'only' one of the implementations (the reference) of ECMA-262 (careful, in Standards language, subtitles usually are there to illustrate, but are not normative). If you feel that I abused this fact by using 'nickname', I apologize: I should have used "ECMA-262-compliant-language" all the time. IE will NOT load script files and will NOT interprete ECMA-262 compliant code if said code isn't loaded with type="text/javascript" (or, alternatively, text/jscript); which, according to RFC4329 section 7 (2006), is obsolete. If you try loading scripts using a type of "application/ecmascript", IE fails by design: https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=338278 I did mention that I'd like DOM 2 events ON TOP of Javascript support; I also made the distinction that Javascript was created even before a standardized HTML DOM was considered. If you consider that ECMA-262 compliant languages can (and, in a browser, need to) operate with a document through that document's object model, then you'll understand that better Javascript support would work even better with better DOM support. But then, I'll spell it out for you: I'd like Javascript support AND better DOM compliance from IE. Clear enough? And here I go again, writing more text in comment than there was in the OP. Geeze...
Anonymous
July 28, 2009
The comment has been removed
Anonymous
July 28, 2009
@Joe: So OK when Microsoft spams me over and over in my server logs, but not OK for me to suggest a reasonable protest. Gotcha.
Anonymous
July 28, 2009
Brianary: Suggesting that people annoy the IE team (who clearly have plenty on their plate) is simply immature and counter-productive. Mitch: I notice that you're already changing your story, and now correctly note that IE loads scripts specified with the text/jscript type as well. I think you'll soon find that it accepts a few more... keep looking... If you're going to critique someone, it's important to be factual.
Anonymous
July 28, 2009
@Joe: it accepts other types - but not for ECMA-262 compliant languages: the others are for VBscript, and there's one for XML (which, as a meta-language, will require you to provide your programming language description on top of your program - we're a bit out of webpage scripting here, don't you think?). Check again the address I provided (pointing to an MS bug report with complete summary). 'text/jscript' isn't recognized by Firefox; Opera and KHTML/Webkit-based browsers do parse and run it, though - they do include at least partial implementations of the IE DOM (using a specific type could be considered a form of browser detection, see). Still, Jscript isn't Javascript, and isn't Ecmascript: it's an ECMA-262 revision 3 compliant programming language. So, to sum up:

if the topic is still "is Jscript just like Javascript", then the answer is still no;
is Javascript the name for the norm? No;
is Ecmascript the norm or the reference implementation of a norm? It's a reference implementation of the ECMA-262 standard, and could be considered the necessary, compatible subset of all ECMA-262 compliant languages;
can IE run Javascript? No, as Javascript is Netscape's superset implementation of an ECMA-262 compliant language, of which compatible implementations are used by all GUI-based, majority browsers but IE;
Can IE run Ecmascript? Yes (if tailored to IE's DOM or W3C code DOM 1), as Ecmascript is a subset of Jscript;
does IE recognize the 'application/ecmascript' type, which is the proper Ecmascript MIMEtype according to RFC4329? No, probably because types can be used as a form of browser detection, and IE not implementing the W3C HTML DOM like other browsers do and scripts relying heavily upon the DOM to run, accepting this type would be Bad(tm). So, did I really change my tune compared to my first comment? I explained some of my (admittedly vague and open to misinterpretation) shortcuts; while IE does recognize MIME-types text/javascript and text/jscript, nobody (not even on MSDN) use the latter (which could be considered obsolete, too, as it is improper to use 'text' as a main type for a scripting language), and IE sure as heck doesn't recognize 'application/ecmascript' which is the proper, not obsolete type for Ecmascript, as reference implementation of ECMA-262, of which Jscript is supposed to be a superset, and for which it'd qualify. Dang, I really did write more than the OP now.

Anonymous
July 29, 2009
@Joe: You're right. I shouldn't pick on the poor little mom-and-pop Microsoft. I mean, they are costing my company money, but surely we can withstand annoyance better than they. It wasn't directed exclusively at the IE team, anyway. EricLaw made it clear that the whole organization is to blame for bloating the UA string. Love the ad hominem attack, BTW. Very classy.
Anonymous
July 29, 2009
Re what to call ECMAScript... some history from an interview with Brendan Eich: InfoWorld: What’s the difference between ECMAScript and JavaScript, or are they one and the same? Eich: ECMAScript is the standards name for the language. Its number is ECMA-262 and it’s a name that the standards body came up with because they couldn’t get anybody to donate a trademark that was agreeable to all parties. So there’s an issue with marketing the programming languages. JavaScript would have been the ideal name because that’s what everyone called it and that’s what the books call it. Microsoft couldn’t get a license from Sun so they called their implementation JScript. So ECMA wanted to call it something and they couldn’t get anybody to donate or they couldn’t get everybody to agree to a donation of the trademark, so they ended up inventing ECMAScript, which sounds a little like a skin disease. Nobody really wants it. And so you have this funny [situation] where you have a standard with a funny name or number and then various implementations that have trade names. And the trade names don’t have a huge value, except JavaScript is the common name. It’s in all the books, it’s what people say. It’s what people refer to on "Saturday Night Live."[Editor's note: JavaScript once merited mention during a skit on the show.] source: http://www.infoworld.com/d/developer-world/javascript-creator-ponders-past-future-704
Anonymous
July 29, 2009
The comment has been removed
Anonymous
July 30, 2009
The comment has been removed
Anonymous
July 30, 2009
@EricLaw: I've added a comment to your article arguing against the proper use of the Accept header. That seems a more on-topic forum for this discussion. http://blogs.msdn.com/ieinternals/archive/2009/07/01/IE-and-the-Accept-Header.aspx#9853459
Anonymous
July 30, 2009
The comment has been removed
Anonymous
July 30, 2009
Odd - other browsers don't have any limitation of "read-only" tags. Is IE going to fix these tags in the next release?
Anonymous
July 31, 2009
How to use developer tools with the WebCtrl ? My application embedded IE 8 webCtrl and Web pages are not working in IE. I want to use all developer tools in this scenario
Anonymous
July 31, 2009
@ejor: Sorry, but the IE8 developer tools can only be used within IE8 itself. I believe that you can use VS or an external debugger to debug script in Web Browser controls in your application.
Anonymous
August 05, 2009
@Toman, > Not showing the closing tag of elements is a really poor choice. It makes finding issues very difficult because the visual tree does not represent the code specified by the developer, please add the closing tags back in. Toman, I agree with you but there maybe 2 distinct difficulties here. In some cases, a closing tab is forbidden in HTML 4: eg the <col> element. In some cases, it is optional in HTML 4: <li>, <dt>, etc. and displaying the end tags may confuse the web author. In some cases, the IE dev. tools is just having a bug (most likely related to DOM tree construction of the rendering engine). a) Eg: <col></col/> as explained in a comment in bug 409478: www.gtalbot.org/BrowserBugsSection/MSIE8Bugs/#bug215 b) Eg: <p> element do not close before a non-inline element: www.gtalbot.org/BrowserBugsSection/MSIE8Bugs/#bug74 www.gtalbot.org/BrowserBugsSection/MSIE7Bugs/Unclosed-P-Preceding-Form.html > properties should be listed in alphabetical order. I fully agree with you on this. All debugging tools (not just Microsoft) should do that. All web authoring softwares should output CSS code according to lexico-graphical/alphabetical order of property names so that code can be much more consistent (source code would be easier to review, maintain, figure out, etc) for all interested+involved parties. Shorthand form should also comply with such order: border-color, border-style and then border-width. Alphabetical order is generally well understood, known and would be easy to remember, to apply, to comply with, etc. @ Mitch 74 Please visit, validate and vote for bug 338278 if you haven't done so already. regards, Gérard
Anonymous
August 05, 2009
@Toman, > Not showing the closing tag of elements is a really poor choice. It makes finding issues very difficult because the visual tree does not represent the code specified by the developer, please add the closing tags back in. Toman, I agree with you but there maybe 2 distinct difficulties here. In some cases, a closing tab is forbidden in HTML 4: eg the <col> element. In some cases, it is optional in HTML 4: <li>, <dt>, etc. and displaying the end tags may confuse the web author. In some cases, the IE dev. tools is just having a bug (most likely related to DOM tree construction of the rendering engine). a) Eg: <col></col/> as explained in a comment in bug 409478: www.gtalbot.org/BrowserBugsSection/MSIE8Bugs/#bug215 b) Eg: <p> element do not close before a non-inline element: www.gtalbot.org/BrowserBugsSection/MSIE8Bugs/#bug74 www.gtalbot.org/BrowserBugsSection/MSIE7Bugs/Unclosed-P-Preceding-Form.html > properties should be listed in alphabetical order. I fully agree with you on this. All debugging tools (not just Microsoft) should do that. All web authoring softwares should output CSS code according to lexico-graphical/alphabetical order of property names so that code can be much more consistent (source code would be easier to review, maintain, figure out, etc) for all interested+involved parties. Shorthand form should also comply with such order: border-color, border-style and then border-width. Alphabetical order is generally well understood, known and would be easy to remember, to apply, to comply with, etc. @ Mitch 74 Please visit, validate and vote for bug 338278 if you haven't done so already. regards, Gérard

Share via

Check Out the New Developer Tools Tutorials

Comments

Additional resources